At 09:14 PM 7/5/2007, Henning Schulzrinne wrote:
all? even 5XXs and 6XXs? I'm have a pragmatic attack thinking how
in the world a UAS can process enough of a request to figure out
location is bad, but still error the message because of something
it can't do more fundamentally with the request outside of
location. There aren't that many 5XX and 6XX responses, so I'm not
fighting it - just trying to understand what you want.
I'm not a friend of being overly prescriptive and trying to predict
all cases, including future status codes. In most cases, inserting
the information may not make sense, but it is always harmless, even
if it goes along with a 5xx or 6xx response. After all, both types of
errors may occur at the same time. If the location information is
broken, I want to be told about it, regardless of what other problems
the SIP request had. (Plus, the location error information may have
been inserted along the way by a proxy trying to use it for location
routing. The UAS getting the location error indication shouldn't just
swallow this information - it's useful to the UAC.)
fair -- the text is changed to allow it in all responses
New topic -- Do we want at all to try and tackle mapping of which
location goes with which error, to make sure each receiver of the
response pays attention or ignores what they are supposed to (wrt
locationValues)?
If this is a good idea, would a header parameter sequence number
(mapped between Geolocation header and Geolocation-Error header) do
the trick? I think we'll just need to make sure the numbers don't
replicate another sequence number within the same Call-ID, and not be
universally unique through space and time.
This might be a little too much to take on this late (to the
deadline) or it just might be too silly of an idea *or* do you think
the host ID within the Geolocation-Error header might be enough to
cover this idea.
Henning
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
