Henning Initial thoughts in-line
At 04:16 PM 4/25/2007, Henning Schulzrinne wrote:
During the call today, we discussed error handling in SIP location conveyance and identified two problems: (1) With multiple locations, it is impossible to tell which error (warning) refers to which location. Since location elements may be inserted by proxies and are then invisible to the UAC, the UAC could get an error indication which makes no sense since it refers to another location. (2) The current return-424 model is inappropriate if location-related failures should not cause the call to fail, as will often be the case. (Just because Domino's can't dereference my location URL, it still wants to talk to me about ordering pizza, but I also want to fix that URL.) Thus, my proposal: (1) Define a new Location-Error request (?) and response header, as in Geolocation-Error: "Cannot dereference" ;tag="xkauc" ;code=711 ;source="alice.example.com"
this is interesting, but we have to account for errors that identify *what* was wrong in an LO (value or reference, assuming the dereference worked), and that requires more header parameters - thus making this header larger than this example. Do you think we can merely list the CAtypes that were supplied that were good, and list those that are still necessary by the Location Recipient? Or just the ones still needed, with text stating to include all that was in the original LO *and* "these" new ones?
Another thought, I think this Geolocation-Error shouldn't be in requests (as I don't see a use case for it yet).
However, I do see the need, if this new header progresses through WG consensus as necessary, to extend the Geolocation header that's currently in Conveyance to include this location "tag" header parameter. I think they need to match up so the UAC understands which location, if more than one is in a request (but not more than one inserted by the UAC), the error is referring to.
where tag is a new tag added to a location header. This error can occur in a 424 or any other status code, including a 200. If included in the request, it's used by the UAS in case location handling is delegated to some other proxy. (I'm not sure whether the request header thing is a good idea.) (2) Define a new Accept-* header, as in Accept-Geolocation: sip, http which identifies the dereferencing protocols supported, to avoid the current ugly overloading of the warning messages.
As much as I think this is an easy way of doing this, no vendor that I know of that's doing the Resource-Priority header from RFC 4412, for example, is coding the Accept-Resource-Priority header - also defined in 4412.
Is this a case where this one Accept-* is not being done? Or a case in which most/any Accept-* aren't being done - so why do we keep creating new ones?
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
_______________________________________________ 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
