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

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