Re: [sipcore] Questions on location conveyance and dereferencing

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. 

> -----Original Message-----
> From: ext Elwell, John [mailto:john.elwell@siemens-enterprise.com] 
> Sent: Monday, August 23, 2010 11:47 AM
> To: Hannes Tschofenig; Tschofenig, Hannes (NSN - FI/Espoo); 
> ext Winterbottom, James; sipcore@ietf.org
> 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
>  
> 
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
> > Sent: 23 August 2010 09:38
> > To: Elwell, John; Tschofenig, Hannes (NSN - FI/Espoo); ext 
> > Winterbottom, James; sipcore@ietf.org
> > Subject: Re: [sipcore] Questions on location conveyance and 
> > dereferencing
> > 
> > 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, sipcore@ietf.org
> > 
> > 	Betreff: Re: [sipcore] Questions on location conveyance 
> > and dereferencing
> > 
> > 
> > 	> -----Original Message----- > From: Tschofenig, Hannes 
> > (NSN - FI/Espoo)  > [mailto:hannes.tschofenig@nsn.com]  > 
> > Sent: 16 August 2010 07:27 > To: Elwell, John; ext 
> > Winterbottom, James; sipcore@ietf.org > 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 sipcore@ietf.org 
> > https://www.ietf.org/mailman/listinfo/sipcore
> > 
> > 
> > 
> > 
> 