Subject: Re: [sipcore] Questions on location conveyance and dereferencing

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 23 Aug 2010 10:38:26 +0200

I would use the following HELD request: 
 <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
 <locationType exact="true">
 geodetic
 civic
 </locationType>
 </locationRequest>

Ciao
Hannes

----- Ursprüngliche Nachricht -----
Von: Elwell, John
Gesendet: 23.08.10 11:30 Uhr
An: Tschofenig, Hannes (NSN - FI/Espoo), ext Winterbottom, James, [email-masked]
Betreff: Re: [sipcore] Questions on location conveyance and dereferencing

> -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:[email-masked]] > Sent: 16 August 2010 07:27 > To: Elwell, John; ext Winterbottom, James; [email-masked] > Subject: RE: [sipcore] Questions on location conveyance and > dereferencing > > Hi John, > > > > > 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. > > [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 t
 o implement HTTP-based > dereferencing mechanism. > > > > > XMPP does not provide equivalent functionality of SIP location > > > conveyance. > > > So, another non-issue. > > [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. [JRE] So how does it request LbyV? John > 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 > _______________________________________________ sipcore mailing list [email-masked] https://www.ietf.org/mailman/listinfo/sipcore

---

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

We are talking at cross purposes. If a location recipient receives through SIP location conveyance an LbyR with a scheme he is unable to dereference, how can he request LbyV instead?

John

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: 23 August 2010 09:38
> To: Elwell, John; Tschofenig, Hannes (NSN - FI/Espoo); ext 
> Winterbottom, James; [email-masked]
> Subject: Re: [sipcore] Questions on location conveyance and 
> dereferencing
> 
> 	> -----Original Message----- > From: Tschofenig, Hannes 
> (NSN - FI/Espoo)  > [mailto:[email-masked]]  > 
> Sent: 16 August 2010 07:27 > To: Elwell, John; ext 
> Winterbottom, James; [email-masked] > Subject: RE: 
> [sipcore] Questions on location conveyance and  > 
> dereferencing >  > Hi John,  >   >  > > > 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.  > > [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.  
> >  >  > > > XMPP does not provide equivalent functionality of 
> SIP location > > > conveyance.  > > > So, another non-issue.  
> > > [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.  [JRE] So how 
> does it request LbyV?  John   > 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 >  
> _______________________________________________ sipcore 
> mailing list [email-masked] 
> https://www.ietf.org/mailman/listinfo/sipcore
> 
> 
> 
>

---

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

http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance-03 should define error codes for that purpose. 
Unfortunately, the code you would need is not there. 

> From: ext Elwell, John [mailto:[email-masked]] 
> Sent: Monday, August 23, 2010 11:47 AM
> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - FI/Espoo); 
> ext Winterbottom, James; [email-masked]
> Subject: RE: [sipcore] Questions on location conveyance and 
> dereferencing
> 
> We are talking at cross purposes. If a location recipient 
> receives through SIP location conveyance an LbyR with a 
> scheme he is unable to dereference, how can he request LbyV instead?
> 
> John
>  
> 
> >          <locationRequest 
> xmlns="urn:ietf:params:xml:ns:geopriv:held">

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 23 Aug 2010 14:02:46 +0300

I looked a bit further and found the error you want in a former version of the document: 
http://tools.ietf.org/html/draft-ietf-sip-location-conveyance-08

"3.4.8 Geolocation-Error Code 8 Cannot Dereference"

It would be more useful to have something like "Geolocation-Error Code 20 Unsupported Scheme - RFCXYZ desired"

In the meanwhile I tend to agree that it is probably simpler to go for the approach that you and James had suggested, namely to indicate the HTTP based URI scheme as mandatory to implement and to always hand out HTTP URIs and potentially others as well, if available, or asked for. 

Ciao
Hannes

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext 
> Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Monday, August 23, 2010 1:51 PM
> To: ext Elwell, John; Hannes Tschofenig; ext Winterbottom, 
> James; [email-masked]
> http://tools.ietf.org/html/draft-ietf-sipcore-location-conveya
> nce-03 should define error codes for that purpose. 
> _______________________________________________
> sipcore mailing list
> [email-masked]