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

James

We won't say anything like "MUST only use sip/sips/pres/cid, and MUST NOT 
...".  I don't believe we will take a negative tone with what isn't allowed 
in this respect, but we will state explicitly what is defined for use.

We will likely state something like this:  ' this document defines usage of 
the sip, sips, pres and cid schemas for location conveyance, and here's how...'

I think Geopriv really needs to look at HTTP as a RFC 3693 "using protocol" 
to tease out any unique characteristics with that protocol.  That 
discussion and review shouldn't bog this document down.  Does this sound fair?

At 06:31 PM 7/26/2006 -0500, Winterbottom, James wrote:
>Brian,
>
>I don't care if you don't mention how to de-reference URI types other
>than sip/sips/cid/pres in the document or not. But I do not want the
>schema artificially constrained to exclude URI types such as HTTP. There
>is clearly not consensus to justify this exclusion, so please leave
>schema unchanged and make your recommendations in the text.
>
>Cheers
>James
>
>
>
>-----Original Message-----
>From: Abbott, Nadine B [mailto:[email protected]]
>Sent: Thursday, 27 July 2006 7:44 AM
>To: Brian Rosen; [email protected]
>Cc: [email protected]
>Subject: RE: [Geopriv] Consensus on changes to location-conveyance
>
>Brian,
>
>Actually, I was thinking that in other industry work which is trying to
>leverage and provide transitional strategies to migrate to using SIP to
>support emergency services, the and long-term solutions that we have
>defined assume a capabity to provide location-by-reference.  I think it
>would be very useful to have this defined in a standard SIP header
>mechanism in such a way that we need not redefine migratory solutions
>that have begun to be implemented. If an HTTPS URI can be used as the
>location-by-reference, this will be helpful, I think.
>
>I don't understand your urgency to make location-by-reference only an
>all-sip-all-the-time thing.
>And from all the other emails on this topic, it didn't seem to me that
>there is a consensus to do this.
>
>Nadine
>
>-----Original Message-----
>From: Brian Rosen [mailto:[email protected]]
>Sent: Wednesday, July 26, 2006 3:15 PM
>To: Abbott, Nadine B; [email protected]
>Cc: [email protected]
>Subject: 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
>
>
>_______________________________________________
>Geopriv mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/geopriv
>
>------------------------------------------------------------------------------------------------
>This message is for the designated recipient only and may
>contain privileged, proprietary, or otherwise private information.
>If you have received it in error, please notify the sender
>immediately and delete the original.  Any unauthorized use of
>this email is prohibited.
>------------------------------------------------------------------------------------------------
>[mf2]
>
>_______________________________________________
>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