[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sipping] I-D Action:draft-schwartz-sipping-nsr-code-00.txt


On Jun 24, 2008, at 6:01 PM, Elwell, John wrote:


David,


-----Original Message-----
From: David Schwartz [mailto:dschwartz at xconnect.net]
Sent: 24 June 2008 13:42
To: Elwell, John
Cc: sipping at ietf.org
Subject: Re: I-D Action:draft-schwartz-sipping-nsr-code-00.txt

Hi John,

First of all I would like to thank you for reading this and
commenting
- I am trying to gather feedback and all comments are welcome.

Let me please explain the underlying motivation and than let me
address you comment.

It all comes down to semantics and automata. Do I want to
give the UAC
initiating the call enough information to possibly take some
corrective action.

3261 defines 404 as follows:

21.4.5 404 Not Found

   The server has definitive information that the user does
not exist
at
   the domain specified in the Request-URI.  This status is also
   returned if the domain in the Request-URI does not match
any of the
   domains handled by the recipient of the request.

Note the word "definitive"

In a SIP URI (non e.164 username) world, the UAS processing the
request has "definitive" information about its own domain.
There is no
point trying the same NON-MODIFIED request at a different
domain since
that other domain will simply route this back to this first domain
that has already responded with a 404 and gave the UAC definitive
information that this is pointless.  As we know all to well,
when the
username is an e.164 number the domain information is usually just
that of the service provider with whom the UAC has a
relationship but
has little or nothing to do with the ability to say anything
definitively about the username.  Sometimes, it may be possible to
answer definitively and in these cases 404 is indeed appropriate. In
other cases however it is semantically wrong to issue a 404
[JRE] I disagree. It is semantically correct to issue a 404, because the service provider has definitive information that the user does not exist 
at the service provider's domain, i.e., at the domain specified in the
Request-URI.
DS: Yes - but this domain is arbitrary - this is kind of like a letter of the law and spirit of the law discussion. By the letter of the law you are right but from a spirit of the law I am pointing out that the domain is arbitrary and hence we can do better than a 404. 


If the Request-URI contains some domain other than the
service provider's domain, the service provider should simply route to
that other domain, so the problem does not arise in that case.







and it
hinders ones ability to automate failover or route advance for these
cases.  The fact that UAC's may be smart enough to take corrective
action on a 404 does not mitigate the inherent ambiguity in the 404
response used for this purpose.
[JRE] I agree that the UAC may have some difficulty figuring it out, but 
how can the service provider's domain figure it out? It knows the user
does not exist in its own domain, but how does it know whether the user 
is likely to exist in some other domain?
DS: All I am saying is that a 404 means "I know it doesn't exist here AND anywhere else" and I am looking for "I know it doesn't exist here" 


John

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________


_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP