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

From: James M. Polk ^lt;jmpolk@cisco.com>
Date: Thu Jul 27 2006 - 14:32:23 EDT

At 04:33 PM 7/27/2006 +0200, Hannes Tschofenig wrote:
>Hi Brian,
>
>are you talking about the end host adding a location-by-reference into the
>SIP header or a proxy doing so?
>
>In any case I don't understand your objection against the usage of HTTP
>and your preference for SIP/SIPS/PREZ?

Hannes - I think Brian has a problem with a SIP doc defining how HTTP
works. He has stated an HTTP doc should do this. We think this HTTP doc
should be very, very short. This SIP doc is allowing an extension to the
URI schemes without going though the SIP WG as a SIP WG item (which is
normally required - and takes a lot of time, because it must first start in
SIPPING).

>Ciao
>Hannes
>
>Brian Rosen wrote:
>>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:nabbott@telcordia.com] Sent: Wednesday, July 26, 2006 2:14
>>>PM To: sip@ietf.org Cc: geopriv@ietf.org 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:Brian.Rosen@neustar.biz] Sent: Tuesday, July 25, 2006 1:38
>>>PM To: sip@ietf.org Cc: geopriv@ietf.org 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 Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv
>>>_______________________________________________ Geopriv mailing
>>>list Geopriv@ietf.org 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
>>sip-implementors@cs.columbia.edu for questions on current sip Use
>>sipping@ietf.org for new developments on the application of sip
>
>
>_______________________________________________
>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 27 Jul 2006 13:32:23 -0500

This archive was generated by hypermail 2.1.8 : Thu Jul 27 2006 - 14:43:13 EDT