Re: I-D Action:draft-kaplan-sipping-interop-bcp-02.txt

> -----Original Message-----
> From: David Schwartz [mailto:[email protected]]
> Sent: Sunday, July 12, 2009 8:22 AM
> 
> I still think that there should be a difference between:
> * I can't help you and no one can (e.g. user is not online - 404)
> * I can't help you do to some temporary issue (network - 503 or otherwise
> - 480)
> * I can't help you but feel free to try elsewhere (e.g. cannot find a
> route to the target do to one of many reasons)
> 
> And I still feel that there should be a new response code to this last
> category.
> 
> Your thoughts?

I thought that the last category *is* what a 404 is for, while the first category is a 604. (well, I assume you don't actually mean "cannot find a route to the target" for the last category - because that is what a 480 is for :)

It just happens that in practice hardly anyone ever sends a 604, even though they maybe should.  So if devices today send 404 for both case-1 and case-3 when they already have two different response codes for the two cases, then why would they change that behavior just because a new response code is created for one of the cases?  Or am I missing the gist of the problem?

-hadriel
p.s.  My guess is that it's not because they can't generate a 604 physically, but rather that the systems can't consistently and programmatically know when it would be correct to do so.  It's kind of a bold statement to say "I know you can't reach this user by any means anywhere", when the URI is an E.164 number.  For example some products only ever issue a 604 response when the ENUM server has an explicit entry for the target number, and the entry's NAPTR is the VOID/UNUSED type.  But otherwise they're dealing with provisioned route tables and HLR's and such, which may simply not have an entry for a number that isn't active, vs. an actual entry which explicitly says "not-active".  But that's just my personal theory.

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