Re: [sipcore] Questions on location conveyance and dereferencing

It seems to me we should mandate that RFC 3856 be used. I don't have an opinion as to what, if anything, we should say about RFC 4661, loc-filters, etc..

John

> -----Original Message-----
> From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] 
> Sent: 13 August 2010 09:24
> To: Elwell, John; sipcore@ietf.org
> Subject: RE: Questions on location conveyance and dereferencing
> 
> Hi John,
> 
> Those are valid points. For the most part I have really only 
> been thinking about using HTTP URIs for HELD dereferencing in 
> this header, so I haven't given a whole lot of thought to SIP 
> outside of loc-filters.
> 
> Do you have a recommendation?
> 
> Cheers
> James
> 
> ________________________________________
> From: Elwell, John [john.elwell@siemens-enterprise.com]
> Sent: Friday, August 13, 2010 3:19 AM
> To: Winterbottom, James; sipcore@ietf.org
> Subject: RE: Questions on location conveyance and dereferencing
> 
> James,
> 
> Thanks. True, this could be used, but the point is, if I 
> receive a SIP/SIPS-URI in a SIP Geolocation header field, how 
> do I know what to use (e.g., RFC 3856, RFC 3856 + RFC 4661, 
> RFC 3856 + RFC 4661 + loc-filters, some other event package). 
> Unless something is specified in location-conveyance, how do 
> I, as location recipient, know which event package and 
> extensions are likely to work at the referenced resource?
> 
> John
> 
> 
> > -----Original Message-----
> > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> > Sent: 12 August 2010 09:27
> > To: Elwell, John; sipcore@ietf.org
> > Subject: RE: Questions on location conveyance and dereferencing
> >
> > Hi John,
> >
> > I think you could use this as a basic location subscription:
> > http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-11
> >
> > There is already a lot of protest against point 2, and I
> > believe that this is going to be fixed.
> >
> > Cheers
> > James
> >
> > ________________________________________
> > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On
> > Behalf Of Elwell, John [john.elwell@siemens-enterprise.com]
> > Sent: Thursday, August 12, 2010 3:21 AM
> > To: sipcore@ietf.org
> > Subject: [sipcore] Questions on location conveyance and 
> dereferencing
> >
> > 1. Draft-ietf-sipcore-location-conveyance-03 defines PRES,
> > SIP and SIPS URI schemes for LbyR. For SIP and SIPS, there
> > seems to be an absence of specification of what event package
> > to use when submitting a SIP or SIPS SUBSCRIBE request for
> > dereference purposes. If it is not defined in this
> > specification, where is it defined?
> >
> > 2. Concerning PRES-URIs, we have the following text in 4.6:
> > "If a location URI is included in a SIP request, it MUST be a SIP-,
> >    SIPS- or PRES-URI.  When PRES: is used, as defined in 
> [RFC3856], if
> >    the resulting resolution resolves to a SIP: or SIPS: URI, this
> >    section applies."
> >
> > The words "this section applies" are rather strange, because
> > there is little else in this section. Maybe in a previous
> > iteration there was more information here (on how to use a
> > SIP/SIPS URI for dereference purposes). As things stand, the
> > absence of information on how to resolve a SIP- or SIPS-URI
> > applies also to PRES-URIs.
> >
> > 3. Also there is nothing to say what to do if the PRES URI
> > fails to resolve to a SIP or SIPS URI.
> >
> > 4. The "MUST be a SIP-, SIPS- or PRES-URI" text in cited
> > above seems to preclude the addition of future URI schemes,
> > which seems to be in conflict with 8.6 (registry
> > establishment for location URIs).
> >
> >
> > John
> > _______________________________________________
> > sipcore mailing list
> > sipcore@ietf.org
> > https://www.ietf.org/mailman/listinfo/sipcore
> >
> 