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

From: Sumit Garg <[email-masked]>
Date: Tue, 24 Jun 2008 08:34:17 -0700 (PDT)

I agree, From the definition in 3261 it is apparent
that 404 mean it does not exist here....

In case, you wanted to say something like "It does not
exist here AND anywhere else" you would need a 604
Does not Exist Anywhere.
"The reasonable man adapts himself to the world; the
unreasonable one persists in trying to adapt the world
to himself. Therefore all progress depends on the
unreasonable man."
-- George Bernard Shaw

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Elwell,
John
Sent: Tuesday, June 24, 2008 11:27 AM
To: David Schwartz
Cc: [email-masked]
Subject: Re: [Sipping] I-D
Action:draft-schwartz-sipping-nsr-code-00.txt

David,

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of David
Schwartz
> Sent: 24 June 2008 16:13
> To: Elwell, John
> Cc: [email-masked]
> Subject: 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:[email-masked]]
> >> Sent: 24 June 2008 13:42
> >> To: Elwell, John
> >> Cc: [email-masked]
> >> 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"
[JRE] And I would contend that 404 means "I know it
doesn't exist here".

John
_______________________________________________
Sipping mailing list 
https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of
SIP Use [email-masked] for questions
on current sip Use [email-masked] for new developments
of core SIP

Forever,
Sumit
"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."
-- George Bernard Shaw

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Sumit Garg <[email-masked]>
Date: Tue, 24 Jun 2008 14:18:11 -0700 (PDT)

You definitely need to use a 6xx class response to say
"cannot be found anywhere" as the text sounds global
to me. 4xx responses per se are Server level
responses....
I am unclear about the reason for resistance  to 604
for Global failure.
It appears to me the only reason you are looking for a
new code is because entities are using 404 and not 604
in scenarios where they definitely know the end -
entity cannot be reached anywhere.

With the new mechanism:
I am not sure shifting to onus the the UAS to say
whether it can be found anywhere else is wise..as in
that case it will need to implement a mechanism to
find out the same....in the absence of which the
logical thing to do would be to always send the new
4xx code as only thing a server can say for sure is
about its authoritative domain. If there indeed was
such a mechanism available at the UAS it could very
well send a 604. The UAC would still need to find out
a way to route to the same.