Subject: Location-conveyance: ISSUE #4 - error indications (was RE: [Sip] SIP location conveyance: error indication)

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 10 May 2007 03:23:36 +0200

(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-masked]] 
> 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-masked] for questions on current sip 
> Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip