Re: [sipcore] Questions on location conveyance and dereferencing

Good questions, John! 

I don't know why we need SIP/SIPS and the PRES URI scheme. Wouldn't
SIP/SIPS already be sufficient? 

If you only use RFC 3856 then you have no way to filter location; you
might end up getting a lot of notifications. Still, it works. 

If you use RFC 3856 with the location filters then you can additionally
limit the number of notifications you get. The location filters works
reuses RFC 4661 to a certain extend but my intention was that you do not
need to implement the full RFC 4661 for location filtering because you
do not need it  nor does it seem to be useful either. Using RFC 4661 on
the other hand would not get you too far in the area of location
filtering. 

So, the options are: 

A) RFC 3856
B) RFC 3856 + loc-filters. 

If you send a SUBSCRIBE with loc-filters and the other party does not
understand it then the error handling in RFC 3856 should kick in.  

Does this make sense to you? 

Ciao
Hannes

PS: With the work on loc-filters I suggested to get rid of RFC 4661
completely and to build loc-filters on top of something entirely
different (for example a scripting language like JavaScript) but the
group did not like it. 

> -----Original Message-----
> From: sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Winterbottom, James
> Sent: Friday, August 13, 2010 11:24 AM
> To: Elwell, John; sipcore@ietf.org
> Subject: Re: [sipcore] 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
> 