Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-03

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Jul 2010 23:10:46 -0400

I finally got around to reading this version of the document.
Most stuff I noticed has already been mentioned and I won't repeat.
I did notice one thing I haven't seen mentioned before:

Section 4.2 says that a 424 response must not be used if there was no 
Geolocation header in the request.

What if the UAC does not understand Geolocation and inserts no 
Geolocation header. However an intermediary (proxy-1) *does * insert a 
Geolocation header. Then a downstream intermediary (proxy-2) takes issue 
with that and returns a 424 response.

ISTM there needs to be a requirement that the intermediary inserting the 
Geolocation header handle any 424 errors that might result from it, thus 
shielding the UAC from those.

	Thanks,
	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 21 Jul 2010 22:29:54 -0500

At 10:10 PM 7/21/2010, Paul Kyzivat wrote:
>Section 4.2 says that a 424 response must not be used if there was 
>no Geolocation header in the request.

This was to prevent exactly the scenario you indicate below (i.e., 
the UAC could go belly-up). It might be considered too rigid at the 
moment though (the alternative you mention below).

>Geolocation header. However an intermediary (proxy-1) *does * insert 
>a Geolocation header. Then a downstream intermediary (proxy-2) takes 
>issue with that and returns a 424 response.

then the UAC will receive the 424 and not have a clue what to do with 
it because it cannot correct something it does not understand in the 
first place.

>ISTM there needs to be a requirement that the intermediary inserting 
>the Geolocation header handle any 424 errors that might result from 
>it, thus shielding the UAC from those.

Do you think we can state this?  I'm thinking from a purest protocol 
pov, that seems to me to break SIP's e2e model of communication, 
especially when involving a literal proxy - and not some other form 
of SIP intermediary (e.g., b2bua or sbc that are made to do just this).

I was always erring on the side of caution here, but you're the big 
cheese now ;-) so I'm willing to go with this.

James

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Jul 2010 09:43:44 -0400

James M. Polk wrote:
> This was to prevent exactly the scenario you indicate below (i.e., the 
> UAC could go belly-up). It might be considered too rigid at the moment 
> though (the alternative you mention below).
> 
> 
>> Geolocation header. Then a downstream intermediary (proxy-2) takes 
> then the UAC will receive the 424 and not have a clue what to do with it 
> because it cannot correct something it does not understand in the first 
> place.
> 
> 
> especially when involving a literal proxy - and not some other form of 
> SIP intermediary (e.g., b2bua or sbc that are made to do just this).

Well, a forking proxy can send a request one place, catch an error 
response from that and then send the request someplace else. And a proxy 
can always send an error response of its own construction. I don't see 
dealing with this case as any different. Proxy 1 could:

- catch the 424 error and then resend the request with some different 
Geolocation

- catch the 424 and then send some different error response back to the UAC.

> cheese now ;-) so I'm willing to go with this.

Hmm. I don't know if I want to be a "cheese", and whatever kind of 
cheese I am doesn't really matter here. :-)

	Thanks,
	Paul

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 23 Jul 2010 08:14:04 +0800

> of

No harm in making a statement about this.  Of course, this sort of behaviour could simply be implied.  If the intermediary is acting as a B2BUA, when it adds a feature, it can (and should) absorb the consequences of that.  For geolocation, if it adds the header, it must be prepared for the consequences of that (424).

I'll leave it to the discretion of the editors how much they want to dance around the sensitivities.  But you could just say:

An intermediary that adds a geolocation header MUST be prepared to handle any errors that this might result in, including a 424 response.  The intermediary might then translate this error into an error that the UAC is known to support, or...

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 23 Jul 2010 08:43:59 +0800

This may be ignorance on my part, but I am going to assume that this is not the first new header added to the SIP since RFC3261, and so it is also not the first case where an error might come back from about a header that has been inserted along the way.

What happens in these other cases?

Cheers
James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Thomson, Martin
> Sent: Friday, 23 July 2010 10:14 AM
> To: Paul Kyzivat; James M. Polk
> Cc: SIPCORE
> Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-03
> 
> No harm in making a statement about this.  Of course, this sort of
> behaviour could simply be implied.  If the intermediary is acting as a
> B2BUA, when it adds a feature, it can (and should) absorb the consequences
> of that.  For geolocation, if it adds the header, it must be prepared for
> the consequences of that (424).
> 
> I'll leave it to the discretion of the editors how much they want to dance
> around the sensitivities.  But you could just say:
> 
> An intermediary that adds a geolocation header MUST be prepared to handle
> any errors that this might result in, including a 424 response.  The
> intermediary might then translate this error into an error that the UAC is
> known to support, or...
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 22 Jul 2010 23:51:03 -0500

At 07:14 PM 7/22/2010, Thomson, Martin wrote:
>behaviour could simply be implied.

right now it is assumed, but you're right - saying something, as long 
as it's accurate is better.

>If the intermediary is acting as a B2BUA, when it adds a feature, it 
>can (and should) absorb the consequences of that.  For geolocation, 
>if it adds the header, it must be prepared for the consequences of that (424).
>
>I'll leave it to the discretion of the editors how much they want to 
>dance around the sensitivities.  But you could just say:

I like this, but I'm concerned about what could happen about an 
intermediary that includes a geolocation header value and causes 
another - non-424 - error response? I'm not sure how that could come 
about (that is, only from the insertion of the geolocation header 
value).  I get the intent here, but how about this refinement below

>An intermediary that adds a geolocation header MUST

s/MUST/SHOULD

>be prepared to handle any errors that this might result in, 
>including a a 424 response.

s/including a 424 response/and MUST handle the 424 response instead 
of leaving this for a UAC to potentially blindly deal with.

>The intermediary might

s/might/will

>  then translate this error into an error that the UAC is known to support

(including). This is behavior paramount if the intermediary inserts 
the initial geolocation header value into a SIP request.

>, or...

here is the edited paragraph in whole, above is the editing version

    "An intermediary that adds a geolocation header SHOULD
     be prepared to handle any errors that this might
     result in, and MUST handle the 424 response instead of
     leaving this for a UAC to blindly deal with. The
     intermediary will then translate this error into an
     error that the UAC is known to support. This
     behavior is paramount if the intermediary inserts the
     initial geolocation header value into a SIP request."

thoughts?

James

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 23 Jul 2010 09:43:35 +0200

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of James M. Polk
> Sent: 23 July 2010 05:51
> To: Thomson, Martin; Paul Kyzivat; James M. Polk
> Cc: SIPCORE
[JRE] I agree in principle with this proposal. Even if the UAC DOES support location-conveyance, receipt of a 424 response when it has not included a location in the request would be confusing, to say the least. That is what is rather unique about a 424 response - it relates to a specific header field, whereas most other SIP responses are less specific. A 4xx response says it is a bad request. A 424 response says it is a bad location, so the implication is that by removing or rectifying the location and transmitting a new request, it might be acceptable. This just doesn't make sense to a UAC that has not included location in the first place.

In fact, we already have in the draft the statement:
"A 424 MUST NOT be sent in response 
   to a request that lacks a Geolocation header entirely, as the user 
   agent in that case may not support this extension at all."
This text seems to imply that a UAC would not expect to receive a 424 if it has not inserted Geolocation, whether or not it supports Geolocation.

Instead of 
"The intermediary will then translate this error into an error that the UAC is known to support."
perhaps we should something like:
"The intermediary will then translate this error into an error that is likely to be meaningful to the UAC."

Concerning the words:
"This behavior is paramount if the intermediary inserts the initial geolocation header value into a SIP request."
I am not sure what value this sentence adds - can we remove it?

John