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

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.

> -----Original Message-----
> From: Winterbottom, James
> Sent: Friday, 23 July 2010 3:45 AM
> To: Paul Kyzivat; DOLLY, MARTIN C (ATTLABS)
> Cc: Thomson, Martin; jmpolk@cisco.com; sipcore@ietf.org
> 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
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: Friday, 23 July 2010 11:41 AM
> > To: DOLLY, MARTIN C (ATTLABS)
> > Cc: Winterbottom, James; Thomson, Martin; jmpolk@cisco.com;
> > sipcore@ietf.org
> > Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-03
> >
> > 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: sipcore-bounces@ietf.org <sipcore-bounces@ietf.org>
> > > To: Thomson, Martin <Martin.Thomson@andrew.com>; Paul Kyzivat
> > <pkyzivat@cisco.com>; James M. Polk <jmpolk@cisco.com>
> > > Cc: SIPCORE <sipcore@ietf.org>
> > > 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: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org]
> 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
> > >> sipcore@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/sipcore
> > > _______________________________________________
> > > sipcore mailing list
> > > sipcore@ietf.org
> > > https://www.ietf.org/mailman/listinfo/sipcore