Re: [sipcore] location-conveyance-03 just submitted

["James M. Polk" <[e-mail]>]

At 07:09 PM 7/13/2010, Thomson, Martin wrote:
>Hi James,
>
>
> > >The draft doesn’t really justify the existence
> > >of the "geolocaocation" option tag.
> >
> > what would justify it?
> >
> > the purpose of an option-tag is the ability to
> > indicate support for an extension (whether
> > optional or required), and to respond with
> > whether or not an extension is supported or
> > unsupported. This indication can be quite
> > important for communicating SIP elements to
> > understand support for (or not). I'm confused...
>
>Why is indicating support for (or requirement 
>of) this particular feature important?  If a UAC 
>includes the header, is that not sufficient 
>indication of support?  What reason might a UAC 
>have for requiring that the UAS supports the feature?

if I hasn't answer this point, here are a couple of reasons for this
- a UAS can be responding to an OPTIONS query, 
indicating it supports geolocation too.
- a UAC could include this option tag in a 
OPTIONS request, even though it included no geolocation header value.
- a UAS could need this to indicate it doesn't 
support an extension in SIP. Sending this option 
tag in an Unsupported header value is important in this case


>One justification for Supported might be that it 
>is not possible to send 424 without some prior 
>acknowledgement that the code is understood by 
>the UAC.  That might be sufficient.

I don't believe an Unsupported header value can 
contain an option tag it didn't support that 
wasn't in the SIP request it is responding to.


James