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

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Jul 2010 21:41:06 -0400

SIP *does* have a compatibility mechanism. If the 424 *does* get back to 
an unaware UAC, then it will be treated equivalently to a 400.

The problem arises if that is an insufficient way of dealing.
The design of the 424 response is based on the assumption that the 
recipient will understand it and make a suitable retry. An unaware UAC 
won't do that.

The words Martin offered seem sufficient to me. If the responsible proxy 
is satisfied with the consequences of allowing the UAC to get the 424, 
then that too is ok.

It could be left unstated, on the assumption that it will be evident to 
an informed developer. But in my experience much of the stuff that seems 
evident to us turns out *not* to be evident to many developers.

	Thanks,
	Paul

DOLLY, MARTIN C (ATTLABS) wrote:
> A good protocol would have a compatibility mechanism...mmm
> Martin C. Dolly
> Sent to you by AT&T... America's Fastest Mobile Broadband Network. Rethink Possible.
> +1.609.903.3360
> 
> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: Thomson, Martin <[email-masked]>; Paul Kyzivat <[email-masked]>; James M. Polk <[email-masked]>
> Cc: SIPCORE <[email-masked]>
> Sent: Thu Jul 22 20:43:59 2010
> Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-03
> 
> 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
>>
>>>>> 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).
>> 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
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Thu, 22 Jul 2010 21:02:24 -0400

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Thomson, Martin <[email-masked]>; Paul Kyzivat <[email-masked]>; James M. Polk <[email-masked]>
Cc: SIPCORE <[email-masked]>
Sent: Thu Jul 22 20:43:59 2010
Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-03

Cheers
James

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 23 Jul 2010 09:45:22 +0800

Hi Paul,

I am okay with all of that, but it seems like what is being proposed should apply to any head that a proxy may insert, rather than just something that specific to the geolocation header case.

I don't for one second suggest that putting something to this effect in the location conveyance draft is a bad idea, but perhaps a general statement to the same effect would be worth adding to something like the 3261 core fixes document also.

Cheers
James

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, 23 July 2010 11:41 AM
> To: DOLLY, MARTIN C (ATTLABS)
> Cc: Winterbottom, James; Thomson, Martin; [email-masked];
> [email-masked]
> > To: Thomson, Martin <[email-masked]>; Paul Kyzivat
> <[email-masked]>; James M. Polk <[email-masked]>
> > 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.
> >

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 25 Jul 2010 03:14:55 +0800

We could leave it unspecified and rely on people's intelligence, or, we could do everyone a favour and give a few little clues for each and every new header.

Come the rewrite of 3261 (hah), this collected wisdom could be accumulated.  It doesn't seem like a big problem right now.

> From: Winterbottom, James
> Sent: Friday, 23 July 2010 3:45 AM
> To: Paul Kyzivat; DOLLY, MARTIN C (ATTLABS)
> Cc: Thomson, Martin; [email-masked]; [email-masked]
> Subject: RE: [sipcore] draft-ietf-sipcore-location-conveyance-03
> 
> Hi Paul,
> 
> I am okay with all of that, but it seems like what is being proposed
> should apply to any head that a proxy may insert, rather than just
> something that specific to the geolocation header case.
> 
> I don't for one second suggest that putting something to this effect in
> the location conveyance draft is a bad idea, but perhaps a general
> statement to the same effect would be worth adding to something like
> the 3261 core fixes document also.
> 
> Cheers
> James
> 
> 
> 
> 
> 
> > >> From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf
> > >> Of Thomson, Martin
> > >> of that.  For geolocation, if it adds the header, it must be
> prepared
> > for
> > >> I'll leave it to the discretion of the editors how much they want
> to
> > dance
> > >> intermediary might then translate this error into an error that
> the UAC
> > is
> > >> known to support, or...

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 25 Jul 2010 07:18:17 -0500

I agree Paul -- adding text is a good idea to cover this scenario

James

At 08:41 PM 7/22/2010, Paul Kyzivat wrote:
>SIP *does* have a compatibility mechanism. If the 424 *does* get 
>back to an unaware UAC, then it will be treated equivalently to a 400.
>
>recipient will understand it and make a suitable retry. An unaware 
>UAC won't do that.
>
>The words Martin offered seem sufficient to me. If the responsible 
>proxy is satisfied with the consequences of allowing the UAC to get 
>the 424, then that too is ok.
>
>It could be left unstated, on the assumption that it will be evident 
>to an informed developer. But in my experience much of the stuff 
>that seems evident to us turns out *not* to be evident to many developers.
>
>         Thanks,
>         Paul
>
>>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.