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

Nadine

Are you saying that it's your opinion sip-location-conveyance MUST define an
HTTP dereference procedure?

If you do, why?  What is the use-case or requirement?

Would it not be pretty reasonable to require a separate document that
defines a location-by-reference mechanism, protocol, and geopriv "using
protocol" analysis?  If that document specifically extended what was allowed
in the location header, would that not be reasonable?

I think we have to include "A" dereference mechanism in the
location-conveyance document.  It seems just including sip/sips/prez is a
reasonable, all-sip-all-the-time approach IN THIS DOCUMENT.  That certainly
does not preclude another document describing another way.

Doesn't it seem just a little weird to have a sip-location-conveyance
document describing any kind of http based location conveyance
(de-reference) protocol, especially one created whole cloth without any
other parts?

Doesn't it seem in keeping with the geopriv approach that in order to have
another "using protocol" it has to have a geopriv review?  That is what
leads to restricting the URI schemes.  Would you prefer to let it be wide
open, so any protocol anyone thinks about can be used with the location
header?  I can't see geopriv going along with that.  We're going to make it
a one line ABNF to add a new scheme to the list of allowed schemes.

It seems to me that if it's desired to define some bare-bones HTTP location
by reference protocol, then that should be a separate document, which can
easily extend the allowable schemes in the Location header.  I'm not sure it
might be better to define ALL of that in the L7 protocol, but I wouldn't be
opposed to a simple "raw GET" RFC as long as it got a full geopriv review.
I just don't see where it makes any sense to force that into a sip document.

Brian

> -----Original Message-----
> From: Abbott, Nadine B [mailto:[email protected]]
> Sent: Wednesday, July 26, 2006 2:14 PM
> To: [email protected]
> Cc: [email protected]
> Subject: RE: [Geopriv] Consensus on changes to location-conveyance
> 
> 
> I don't agree that there is a consensus to preclude the use of HTTP.
> I would favor not placing your proposed restriction on the URI scheme
> for expressing a location reference in the SIP location conveyance
> draft; or at least including HTTP as a valid location-reference URI
> type.
> 
> Regards,
> Nadine Abbott
> 
> -----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.
> 
> 2. Dereferencing location-by-reference.  We had initially proposed to
> document a process to use a raw HTTP(S) Get to dereference.  There was a
> lot of discussion, and then I made a new proposal, see item 6.
> 
> 3. We proposed to allow a Reason header with a 424 Bad Location
> response.  This seems to be acceptable to the WG.  Geopriv will create
> and populate the registry in a separate draft.
> 
> 4. We proposed to explicitly allow hop-by-hop TLS security for location
> when the endpoint wished to allow routing based on location.  We further
> proposed to interpret "Do not Distribute" flags as allowing sending of
> the location to the routing database (LoST for example).  Hannes pointed
> out that there was a proposal to allow two Location headers, one of
> which could be used for routing and another for onward forwarding to the
> recipient.  Hannes' message seemed to agree that "Do not distribute"
> would allow sending of the location to the routing-by-location database,
> but would obligate the proxy that did that to remove the location before
> it forwarded the message.  There were no other messages on this thread.
> We conclude that allowing hop-by-hop security for location based routing
> is acceptable, and Do Not Distribute DOES allow forwarding to a routing
> database, but requires that the proxy doing the location based route to
> remove the location it uses for that purpose.
> 
> 5. We proposed to create a parameter and a registry to distinguish
> multiple ways to dereference a location where HTTP(S) was the transport.
> Resolution of this issue depends on resolution of issue 6.
> 
> 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.
> 
> If this does not reflect your position, please speak up now.
> 
> Brian
> 
> _______________________________________________
> 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