(As WG chair) Henning provided this proposal a few weeks back.
Since then, there have been a number of clarifications on the proposal, but apparently no alternatives. I would therefore like to make a consensus call on this issue. The call is EITHER: - To progress location conveyance by documenting the proposal of Henning in the new version. This is obviously agreement on the mechanism, than any of the finer details which could change in the process of documentation and WG discussion. OR - To retain the core of the existing mechanism as documented in -07 of location-conveyance, addressing the remaining comments as fixes to the use of the Warning header, and so on. Unless I header comments otherwise within seven calendar days from this mail, I will assume working group consensus is to go in the direction of Henning's proposal. Note that technical responses and suggestions are welcome on the proposal, but what I am interested in resolving here is the key direction to take the location-conveyance document. Therefore please be clear as to you position on the above question if making any response to this thread. Regards Keith > -----Original Message----- > From: Henning Schulzrinne [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 25, 2007 10:17 PM > To: IETF SIP List > Subject: [Sip] SIP location conveyance: error indication > > 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" > > 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. > > 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
