Re: [sipcore] Questions on location conveyance and dereferencing

Aren't these all forward and backward compatible?

Thus, I had always assumed that you provide a subscription with the minimum set of features that you need.  More advanced features are conveniently ignored by the PA.

> -----Original Message-----
> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
> Behalf Of Elwell, John
> Sent: Friday, 13 August 2010 6:35 PM
> To: Winterbottom, James; sipcore@ietf.org
> Subject: 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
> > >
> >
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore