RE: RE: [Geopriv] Consensus on changes to location-conveyance

In-line... 

> 
> So, you are arguing against proxy insertion of a 
> location-by-reference?

No, if done properly....but reading the latest threads, I get the feeling
that www.whereintheworldisbrianrosen.com is an acceptable reference.

> 
> You don't have a problem with UA insertion of 
> location-by-reference in a Location header?

This assumes the user's presence service (contracted by the user) will do
the right things to protect the privacy/security of the location
information.

> 
> Agree that Location insertion by proxy could assume an INVITE 
> arriving at a proxy without any location.

I suspect there will be many cases where proxy will supplant whatever is
supplied by the user with proxy derived data.

> 
> I've always had a problem with proxy insertion of location 
> because I am worried that proxies will do this without regard 
> to user's wishes.  In an emergency case, however, there are 
> no such worries.  I don't see any difference between by-value 
> and by-reference.

Simplicity?  Call/dispatching failures from dereferencing problems?  Since
emergency calling is the use case driving this, why not opt for less
complexity with a better chance of actually working?

What seems odd is to dismiss L-by-V in the header simply because the L-by-R
has been in this draft for so long.  That is the way I read Keith's message.
Yes, if the stars and moon are all aligned, L-by-R will work, hence
obviating the need for an 'overlapping' L-by-V.  But, if it's a cloudy day,
the complexity associated with dereferencing WILL cause failures.

> 
> Proxies may disregard advice we supply, but Location URIs in 
> Location headers probably should not have any user 
> identification information in either the URI itself, or the 
> resulting PIDF.  If such information is desired, use the AoR.
> 
> De-referencing should always be subject to user rulesets, and 
> would not be any different than by-value except the obvious 
> issue that the owners of the proxy may not provide the user 
> with the facilities to control the ruleset, my original worry.

My worry also.  
  
> 
> Would you not agree that if a proxy is allowed to insert 
> location-by-value, the concerns would be the same?

As pointed out by others, by-value is a moment in time, by-reference makes
current information available for a yet-to-be-specified period.


-Marc-

> 
> Brian
> 
> 
> 
> > -----Original Message-----
> > From: Marc Linsner [mailto:[email protected]]
> > Sent: Tuesday, July 25, 2006 6:17 PM
> > To: 'Peterson, Jon'; 'Andrew Newton'; 'Rosen, Brian'
> > Cc: [email protected]; [email protected]
> > Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location- 
> > conveyance
> > 
> > I have no problem with pidf/pidf-lo/presence.
> > 
> > I have no problem with a ua placing a uri pointing to their 
> presence 
> > service in a header of a sip invite.
> > 
> > Context check:  We're discussing a sip invite (assumed pointed to 
> > emergency
> > service) that arrives at a proxy with zero location information.
> > 
> > I'm the only one that has a problem with any (visited) proxy/LIS 
> > creating a uri that can be de-referenced by anyone without 
> regard to 
> > user security/privacy rules?
> > 
> > -Marc-
> > 
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Peterson, Jon [mailto:[email protected]]
> > > Sent: Tuesday, July 25, 2006 4:42 PM
> > > To: Andrew Newton; Rosen, Brian
> > > Cc: [email protected]; [email protected]; Marc Linsner
> > > Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to 
> > > location-conveyance
> > >
> > >
> > > As Brian points out, the whole point of using PIDF for location 
> > > information was the similarity of the early defined use 
> cases to the 
> > > presence architecture. This certainly included use cases in which 
> > > one wanted to fetch or subscribe to location information. Those 
> > > operations require the existence of a reference, and that 
> reference 
> > > was commonly described as a URI, at the time. Lately, I think the 
> > > idea of having a URI pointing to location information has become 
> > > associated with a specific proposal (i.e. HELD), but clearly
> > > RFC4079 sketched out an architecture for using presence 
> to acquire 
> > > location information and it specifically mentions URIs as 
> a way to 
> > > refer to presence.
> > >
> > > There is no "hidden magic" in any of this. Subscribing to 
> presence, 
> > > and using URIs to indicate presence information, is exhaustively 
> > > specified for SIP. PIDF-LO was designed to reuse all of that work 
> > > and specifically not to require us to go out and reinvent 
> everything 
> > > in order to be able to refer to location information out in the 
> > > network.
> > >
> > > Basically, I support the direction re: bullet 6. I might further 
> > > suggest that the CID URI scheme be permitted in the 
> Location header, 
> > > in order to be able to refer to MIME bodies included in SIP 
> > > messages. I'm also neutral/favorable on using HTTP GET. 
> But I think 
> > > either of these URI schemes and their usage in the 
> Location header 
> > > could just as well be described in subsequent documents.
> > >
> > > Jon Peterson
> > > NeuStar, Inc,
> > >
> > > > -----Original Message-----
> > > > From: Andrew Newton [mailto:[email protected]]
> > > > Sent: Tuesday, July 25, 2006 1:05 PM
> > > > To: Rosen, Brian
> > > > Cc: [email protected]; [email protected]; Marc Linsner
> > > > Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to 
> > > > location-conveyance
> > > >
> > > >
> > > > For the record, I agree with Brian.
> > > >
> > > > -andy
> > > >
> > > > On Jul 25, 2006, at 3:50 PM, Rosen, Brian wrote:
> > > >
> > > > > When the original PIDF-LO RFC came out, location-by-reference 
> > > > > was defined.
> > > > >
> > > > > You have a URI.  You can exchange the URI for location.
> > > There is a
> > > > > protocol defined for that purpose (SIP SUBSCRIBE).  That
> > > is location
> > > > > by reference.  It also serves as the location update 
> mechanism, 
> > > > > clearly something we need.
> > > > >
> > > > > Some day, there may be other location URI references.  We
> > > don't need
> > > > > to cover them in this draft.  The basic location by
> > > reference horse
> > > > > has left the barn.  Were you planning on creating an RFC that
> > > > specifically
> > > > > disallows a Subscribe on a sip/sips/pres URI to get location?
> > > > > THAT WAS
> > > > > THE POINT OF MAKING IT PART OF A PIDF.
> > > > >
> > > > > I do think there is some value in defining a way to express a 
> > > > > location-by-reference aka presence URI which is not just
> > > the AoR.
> > > > > That
> > > > > is one reason why I want to define the Location URI as
> > > being able to
> > > > > contain a sip/sips/pres URI.  The purpose is to allow 
> a UA or a 
> > > > > proxy to insert location where there is no 
> association between 
> > > > > the
> > > > identity of
> > > > > the SIP user and the location.
> > > > >
> > > > > But that is all I think we need.
> > > > >
> > > > > We have a requirement for proxy insertion of location.  If
> > > > we disallow
> > > > > location-by-reference (which I think is a good idea in
> > > general, but
> > > > > futile in practice), then we would need something like the
> > > > Data URI to
> > > > > support location insertion by proxy.  If we DO allow 
> > > > > location-by-reference, then it also serves to meet 
> the location 
> > > > > insertion by proxy requirement, and we don't need the Data
> > > > URI.  We're
> > > > > looking for a use case which requires proxy insertion by
> > > value, but
> > > > > haven't heard one yet.
> > > > >
> > > > > You can make an argument that you can take the From:,
> > > assume it's an
> > > > > AoR, and SUBSCRIBE to the presence of that AoR to get
> > > location, thus
> > > > > not needing a Location header.  I really think letting the
> > > > Location header
> > > > > specify an alternate presence URI is a good idea.
> > > > >
> > > > > Brian
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Marc Linsner [mailto:[email protected]]
> > > > >> Sent: Tuesday, July 25, 2006 3:29 PM
> > > > >> To: Rosen, Brian; [email protected]
> > > > >> Cc: [email protected]
> > > > >> Subject: RE: [Geopriv] Consensus on changes to
> > > location-conveyance
> > > > >>
> > > > >> In-line.....
> > > > >>
> > > > >>> -----Original Message-----
> > > > >>> From: Rosen, Brian [mailto:[email protected]]
> > > > >>> Sent: Tuesday, July 25, 2006 1:38 PM
> > > > >>> To: [email protected]
> > > > >>> Cc: [email protected]
> > > > >>> Subject: [Geopriv] Consensus on changes to 
> location-conveyance
> > > > >>>
> > > > >>> I have put out a number of emails on proposed changes
> > > to location
> > > > >>> conveyance.  Some of them have sparked a number of
> > > comments.  My
> > > > >>> summary of consensus on these issues is:
> > > > >>>
> > > > >>> 1. We proposed to explicitly disallow use of a Data 
> URI, which 
> > > > >>> would allow specification of a Location-by-value in 
> a header.
> > > > >>> There was a lot of list traffic on this, currently in the 
> > > > >>> state where Keith asked for a real use case for it.
> > > > >>> So far, we don't see a use case that cannot be provided by 
> > > > >>> location-by-reference in a header.  If we don't get 
> a good use 
> > > > >>> case, I think consensus is to disallow 
> location-by-value in a 
> > > > >>> header.
> > > > >>>
> > > > >>
> > > > >> I see a problem here.  Location-by-reference is nothing more 
> > > > >> than
> > > > > 'magic
> > > > >> happens here'!  Please point to a wg item documenting the 
> > > > >> location-by-reference mechanism.  How can you state the 
> > > > >> location-by-reference will cover all the use cases that
> > > > the Data URI
> > > > > would
> > > > >> when location-by-reference hasn't even been defined
> > > > anywhere?  You're
> > > > >> loading up the magic with a lot of assumptions.  
> Location-by- 
> > > > >> reference
> > > > > is
> > > > >> an
> > > > >> individual submission as a solution to a set of requirements 
> > > > >> that
> > > > > haven't
> > > > >> been fleshed-out in geopriv.
> > > > >>
> > > > >> I believe that Henning/Hannes also recognized this
> > > issue, hence the
> > > > >> suggestion of a Data URI.  Dismissing this 
> suggestion based on 
> > > > >> an
> > > > > already
> > > > >> accepted non-existent mechanism seems like getting the
> > > > cart before
> > > > >> the
> > > > >> horse.
> > > > >>
> > > > >> ..........snip
> > > > >>
> > > > >>> 6. We proposed to allow sip/sips and pres: in the
> > > location header.
> > > > >>> I later speculated that if we allow this, it forms a
> > > simple way to
> > > > >>> do location-by-reference, and we could eliminate the
> > > raw HTTP(S)
> > > > >>> Get proposal, with the parameter and registry entirely.
> > >  There was
> > > > >>> some list traffic in favor of this.  Martin Thompson is
> > > skeptical
> > > > >>> that SIP Presence Subscribe/Notify is actually allowed as a 
> > > > >>> geopriv "using protocol".  Several of think that it 
> is.  If we 
> > > > >>> don't get any more comments on this proposal, we will allow 
> > > > >>> sip/sips and pres, not have any
> > > > >>> http(s) resolution text, and not propose a parameter and 
> > > > >>> accompanying registry.
> > > > >>
> > > > >> I certainly think it's more prudent to define the 
> dereferencing
> > > > > mechanism
> > > > >> prior to making claims about the protocol.
> > > > >>
> > > > >> Do I believe location-by-reference will happen?  Probably,
> > > > but making
> > > > >> assumptions about the mechanism now is quite premature.
> > > > >>
> > > > >> -Marc-
> > > > >>
> > > > >>>
> > > > >>> If this does not reflect your position, please speak up now.
> > > > >>>
> > > > >
> > > > > _______________________________________________
> > > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > > This list is for NEW development of the core SIP Protocol Use 
> > > > > [email protected] for questions on current sip 
> > > > > Use [email protected] for new developments on the 
> application of 
> > > > > sip
> > > >
> > > >
> > > > _______________________________________________
> > > > Geopriv mailing list
> > > > [email protected]
> > > > https://www1.ietf.org/mailman/listinfo/geopriv
> > > >
> > 
> > _______________________________________________
> > Geopriv mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip