Subject: [sipcore] Questions on location conveyance and dereferencing

From: "Elwell, John" <[email-masked]>
Date: Thu, 12 Aug 2010 10:21:19 +0200

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 12 Aug 2010 16:26:33 +0800

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: [email-masked] [[email-masked]] On Behalf Of Elwell, John [[email-masked]]
Sent: Thursday, August 12, 2010 3:21 AM
To: [email-masked]
Subject: [sipcore] Questions on location conveyance and dereferencing

John
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 13 Aug 2010 10:19:32 +0200

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:[email-masked]] 
> Sent: 12 August 2010 09:27
> To: Elwell, John; [email-masked]
> Subject: RE: Questions on location conveyance and dereferencing
> 
> Hi John,
> 
> From: [email-masked] [[email-masked]] On 
> Behalf Of Elwell, John [[email-masked]]
> 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?
> 
> 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.
> 
> 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

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 13 Aug 2010 16:24:17 +0800

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 [[email-masked]]
Sent: Friday, August 13, 2010 3:19 AM
To: Winterbottom, James; [email-masked]
Subject: RE: Questions on location conveyance and dereferencing

James,

John

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 13 Aug 2010 10:35:15 +0200

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

> Sent: 13 August 2010 09:24
> 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.
> 
> 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
> 
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 13 Aug 2010 11:37:15 +0300

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. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Winterbottom, James
> Sent: Friday, August 13, 2010 11:24 AM
> Subject: Re: [sipcore] Questions on location conveyance and 
> dereferencing
> 
> Hi John,
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 13 Aug 2010 11:04:20 +0200

In fact, proliferation of URI schemes is a problem. If we have n URI schemes standardized for inclusion in the Geolocation header field, then a recipient would need to support dereferencing for all n schemes. There is no negotiation mechanism whereby the inserter can select a scheme that the recipient is known to support. Sounds like an interop nightmare. Perhaps we should go as far as limiting it to a single scheme: HTTPS (using HELD with identity-extensions)? This would just get you the location, without the rest of presence. Or perhaps we should allow in the Geolocation header field several URIs with different schemes, any of which can reach the same location resource.

John

> From: Tschofenig, Hannes (NSN - FI/Espoo) 
> [mailto:[email-masked]] 
> Sent: 13 August 2010 09:37
> To: ext Winterbottom, James; Elwell, John; [email-masked]
> Subject: RE: [sipcore] Questions on location conveyance and 
> dereferencing
> 
> Good questions, John! 
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 13 Aug 2010 17:14:19 +0800

Hi John,

I am inclined to agree that proliferation of URI schemes may be a problem. I am also inclined to think that there really aren't that many common URI schemes with multiple interpretation with regard to how you get location information from them. I could be wrong here though.

As far as the HELD side of things go, I was really thinking that you would get a URI from the LIS that uniquely identifies the Target/resource, as is described in the dereference draft.

Previous revisions of the conveyance draft have allowed multiple header instances and it would have been possible to include additional URI schemes by adding abother header. I don't really want to go back to this scheme. If you are proposing that a single header may include multiple URI types, this might work, but I would oppose forcing these to be directly specified in the ABNF since this would limit extensibility unnecessarily.

Cheers
James
________________________________________
From: Elwell, John [[email-masked]]
Sent: Friday, August 13, 2010 4:04 AM
To: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James; [email-masked]
Subject: RE: [sipcore] Questions on location conveyance and dereferencing

John

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 13 Aug 2010 11:25:44 +0200

James,

I am not really making a firm proposal, and I am indeed aware of the history of location-conveyance and don't want to go back to the multiple locations model that we had previously. However, for a single location, if there are multiple URI schemes, I see the following possibilities:
- limit the number of URI schemes and say the recipient MUST implement all (the ultimate version of this is to have only a single URI scheme);
- define a limited number (perhaps just one) of MUST implement URI schemes, and allow the conveyance of multiple URIs with different schemes, all referencing the same location resource, at least one of which is a MUST implement scheme;
- have some sort of negotiation mechanism - but I don't want to go there because of adding round-trips, particularly a problem for emergency calls.

Any other possibilities?

John

> Sent: 13 August 2010 10:14
> To: Elwell, John; Tschofenig, Hannes (NSN - FI/Espoo); 
> [email-masked]
> I am inclined to agree that proliferation of URI schemes may 
> be a problem. I am also inclined to think that there really 
> aren't that many common URI schemes with multiple 
> interpretation with regard to how you get location 
> information from them. I could be wrong here though.
> 
> As far as the HELD side of things go, I was really thinking 
> that you would get a URI from the LIS that uniquely 
> identifies the Target/resource, as is described in the 
> dereference draft.
> 
> Previous revisions of the conveyance draft have allowed 
> multiple header instances and it would have been possible to 
> include additional URI schemes by adding abother header. I 
> don't really want to go back to this scheme. If you are 
> proposing that a single header may include multiple URI 
> types, this might work, but I would oppose forcing these to 
> be directly specified in the ABNF since this would limit 
> extensibility unnecessarily.
> 
> Cheers
> James
> In fact, proliferation of URI schemes is a problem. If we 
> have n URI schemes standardized for inclusion in the 
> Geolocation header field, then a recipient would need to 
> support dereferencing for all n schemes. There is no 
> negotiation mechanism whereby the inserter can select a 
> scheme that the recipient is known to support. Sounds like an 
> interop nightmare. Perhaps we should go as far as limiting it 
> to a single scheme: HTTPS (using HELD with 
> identity-extensions)? This would just get you the location, 
> without the rest of presence. Or perhaps we should allow in 
> the Geolocation header field several URIs with different 
> schemes, any of which can reach the same location resource.
> 
> John
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 13 Aug 2010 17:34:49 +0800

Hi John,

Yes, this indeed a tricky one.
I must admit that I am biased here. I think that location has a huge range of application beyond just emergency calling, and I think that a lot of this will be implemented over HTTP, HTML5's geolocation capabilities are just one example. So, if we have to standardize on just one scheme being mandatory then I will argue (probably for a very long time) that HTTP and HELD are the best schemes to mandate.

But again, this is only one option and one opinion. I do think that supporting multiple schemes in the same header may however resolve something things, if we can agree on a MUST implement scheme.

Cheers
James

________________________________________
From: Elwell, John [[email-masked]]
Sent: Friday, August 13, 2010 4:25 AM
To: Winterbottom, James; Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
Subject: RE: [sipcore] Questions on location conveyance and dereferencing

James,

Any other possibilities?

John

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 13 Aug 2010 12:53:29 +0300

John, 

I believe you make it more complicated than it really is. 

We have two mechanisms in SIP Location Conveyance, namely one based on
SIP and the other one based on HTTP. The two clearly provide different
capabilities. 

For emergency services I suspect that for a very, very long time the
different parties will agree, which one they are going to use. The fixed
line operators will opt for the HTTP one and maybe the cellular
operators will go for the SIP based solution. HTTP will more or less be
the baseline. 

For non-emergency services I doubt that SIP location coneyance will be
used anytime in the near future. The reasons is quite simple: some
players will continue to struggle with the business model. Additionally,
most applications use the HTTP-based web (and not SIP). If you look at
the deployment of the W3C geolocation API then you will certainly agree
with me and none of the stuff we are discussing here is relevant.

Hence, the only solution that is available is an end host based
approach; this allows location to be conveyed inband in protocols, such
as the Geolocation API. For the non-emergency service use case the
"negotiation" is quite simple: You send something that isn't understood
by the other party. You get an error back. 

I hope that answered your question. 

Ciao
Hannes

> From: ext Winterbottom, James [mailto:[email-masked]] 
> Sent: Friday, August 13, 2010 12:35 PM
> I must admit that I am biased here. I think that location has 
> a huge range of application beyond just emergency calling, 
> and I think that a lot of this will be implemented over HTTP, 
> HTML5's geolocation capabilities are just one example. So, if 
> we have to standardize on just one scheme being mandatory 
> then I will argue (probably for a very long time) that HTTP 
> and HELD are the best schemes to mandate.
> 
> But again, this is only one option and one opinion. I do 
> think that supporting multiple schemes in the same header may 
> however resolve something things, if we can agree on a MUST 
> implement scheme.
> 
> Cheers
> James
> 
> I am not really making a firm proposal, and I am indeed aware 
> of the history of location-conveyance and don't want to go 
> back to the multiple locations model that we had previously. 
> However, for a single location, if there are multiple URI 
> schemes, I see the following possibilities:
> - limit the number of URI schemes and say the recipient MUST 
> implement all (the ultimate version of this is to have only a 
> single URI scheme);
> - define a limited number (perhaps just one) of MUST 
> implement URI schemes, and allow the conveyance of multiple 
> URIs with different schemes, all referencing the same 
> location resource, at least one of which is a MUST implement scheme;
> - have some sort of negotiation mechanism - but I don't want 
> to go there because of adding round-trips, particularly a 
> problem for emergency calls.
> 
> Any other possibilities?
> 
> John
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 13 Aug 2010 12:14:51 +0200

> Sent: 13 August 2010 10:53
[JRE] I am not sure what you mean here. If I search location-conveyance for "HTTP" I don't find it. I assume HTTP is covered by "absoluteURI" in 4.1, however. In fact there is a conflict - section 4.6 doesn't permit "absolute" URI - it says a location URI MUST be SIP/SIPS/PRES. Furthermore, section 8.6 establishes a registry, which allows other URI schemes beyond SIP/SIPS/PRES to be added - presumably under the umbrella of "absoluteURI", but this too is in conflict with 4.6. Anyway, my interpretation is that the ability to use HTTP is intended, but these three sub-sections are certainly in a mess and don't give much of a clue to this possibility. A more explicit mention of HTTP(S) would certainly be helpful.

> operators will go for the SIP based solution. HTTP will more
[JRE] That in itself is an interop problem. For example, if I deploy an enterprise LIS, how do I know whether it should give out HTTP or SIP URIs to its SIP UAs for inclusion in the Geolocation header field?

> with me and none of the stuff we are discussing here is relevant.
[JRE] Yes, and even if applications use presence, they might use XMPP rather than SIMPLE.

> by the other party. You get an error back.
[JRE] So you try again with something else, and that fails too - not very satisfactory. I think a MUST implement scheme is likely to be the best solution, even if we allow other schemes to be conveyed too.

John

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 13 Aug 2010 18:22:48 +0800

Hi John,

I thought that I had explained earlier that the prose concerning URI restrictions was going to be lifted some to include HTTP and HTTP(S), and I think that this will be reflected in the ABNF in that absoluteURI will probably be the only type included. James P and Jon P please correct me if this last bit is wrong.

When a LIS supporting HELD returns a locationURI, it actually returns a locationUriSet, which contains a set of URIs for different schemes at all point to the same resource. So I think that this addresses your second concern below.

On the MUST implement scheme, I have already provided my preference and justified it.... *8)

Cheers
James

Sent: Friday, August 13, 2010 5:14 AM

John

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 13 Aug 2010 13:41:05 +0300

Hi John, 

> [JRE] I am not sure what you mean here. If I search 
> location-conveyance for "HTTP" I don't find it.

James Polk forgot to add it for a couple of years. We managed to clarify
this aspect recently on the mailing list. 
The next version of the draft (which will hopefully show up before the
next IETF meeting) was promised for this month. 

> [JRE] That in itself is an interop problem. For example, if I 
> deploy an enterprise LIS, how do I know whether it should 
> give out HTTP or SIP URIs to its SIP UAs for inclusion in the 
> Geolocation header field?

In your enterprise LIS for emergency services you will most likely want
to figure out who is going to consume that reference. Quite likely the
PSAP will consume the reference. If so, you better talk to the PSAP
responsible for that specific area. 

> use XMPP rather than SIMPLE.

XMPP does not provide equivalent functionality of SIP location
conveyance. 
So, another non-issue. 

> [JRE] So you try again with something else, and that fails 
> too - not very satisfactory. I think a MUST implement scheme 
> is likely to be the best solution, even if we allow other 
> schemes to be conveyed too.
That's not uncommon for the Web today either. If you get a reference
that you cannot resolve then it fails. 
I have no problem with an extension to HELD asking for a specific type
of reference. Providing both references, a SIP and an HTTP based
reference, back to the end host is not out of question either. 

Ciao
Hannes

> [[email-masked]] On
> > > > > > > Behalf Of Elwell, John

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 13 Aug 2010 16:39:47 +0200

> Sent: 13 August 2010 11:41
> To: Elwell, John; ext Winterbottom, James; [email-masked]
[JRE] Yes, of course, I recall now that there was some clarification on the mailing list in this area.

> responsible for that specific area. 
[JRE] Quite so, except is it likely my VoIP service provider might also want to inspect the location, to confirm correct routing? Then depending on which SP I choose to route that particular call through, they might support different URI schemes? It seems to be a mess not having a MUST implement scheme.

> XMPP does not provide equivalent functionality of SIP location
[JRE] That was not the point I was making. I was simply saying that even applications that support presence might support XMPP rather than SIMPLE, and therefore would not want to implement RFC 3856. Instead they might prefer to use HTTP.

John

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 16 Aug 2010 09:26:57 +0300

Hi John, 

> [JRE] Quite so, except is it likely my VoIP service provider 
> might also want to inspect the location, to confirm correct 
> routing? Then depending on which SP I choose to route that 
> particular call through, they might support different URI 
> schemes? It seems to be a mess not having a MUST implement scheme.

I understand the theoretical concern. 
I have no objections against a mandatory to implement HTTP-based
dereferencing mechanism. 

> [JRE] That was not the point I was making. I was simply 
> saying that even applications that support presence might 
> support XMPP rather than SIMPLE, and therefore would not want 
> to implement RFC 3856. Instead they might prefer to use HTTP.
I am not quite sure which scenario you have in mind. 
If I have an end host that supports XMPP and then gets a location URI
then there is the question of who is going to dereference it. If it is
the end point then it would have to implement the protocol indicated by
the URI scheme. Now, if this happens to be SIP then this end point would
have to implement SIP. The end host could, however, request location by
value instead instead of going through the dance of utilizing a LbyR. 
If the end point does not dereference the LbyR but instead some other
entity then there is the question of how this reference then actually
gets there. 

Ciao
Hannes

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 17 Aug 2010 08:28:45 +0800

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.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Elwell, John
> Sent: Friday, 13 August 2010 6:35 PM
> 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
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 23 Aug 2010 10:30:11 +0200

> Sent: 16 August 2010 07:27
[JRE] So how does it request LbyV?

John