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
>