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

From: "Abbott, Nadine B" <[email-masked]>
Date: Wed, 26 Jul 2006 17:43:32 -0400

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-masked]] 
Sent: Wednesday, July 26, 2006 3:15 PM
To: Abbott, Nadine B; [email-masked]
Cc: [email-masked]
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-masked]]
> Sent: Wednesday, July 26, 2006 2:14 PM
> To: [email-masked]
> Cc: [email-masked]
> 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-masked]]
> Sent: Tuesday, July 25, 2006 1:38 PM
> To: [email-masked]
> Cc: [email-masked]
> 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-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 26 Jul 2006 18:31:16 -0500

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-masked]] 
Sent: Thursday, 27 July 2006 7:44 AM
To: Brian Rosen; [email-masked]
Cc: [email-masked]
Subject: RE: [Geopriv] Consensus on changes to location-conveyance

Brian,

Nadine 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, July 26, 2006 3:15 PM
To: Abbott, Nadine B; [email-masked]
Cc: [email-masked]
Subject: RE: [Geopriv] Consensus on changes to location-conveyance

Nadine

Brian

not distribute"
messages on this thread.
transport.

------------------------------------------------------------------------------------------------
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]

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 26 Jul 2006 22:27:36 -0500

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?

---

From: Andrew Newton <[email-masked]>
Date: Wed, 26 Jul 2006 23:37:12 -0400

On Jul 26, 2006, at 11:27 PM, James M. Polk wrote:

> 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?

Most definitely.  We've had discussions on HTTP as a using protocol  
for 3 years in GEOPRIV, HELD being the latest incarnation.  The first  
proposals ran into serious privacy concerns.  Anything that simply  
says "use HTTP" is an attempt to work around answering the serious  
privacy concerns raised in GEOPRIV.

-andy

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 26 Jul 2006 23:08:31 -0500

>privacy concerns raised in GEOPRIV.

is this said with your WG chair hat on?

It sounds pretty definitive to these ears...

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 26 Jul 2006 23:31:54 -0500

James,

By the restricting of the schema you are saying MUST NOT as that is what
is defined in the ABNF, so if I implement the specification anything
else is invalid. I agree wholeheartedly with Henning's last suggestion,
leave the schema open but only describe the methods you are going to
specifically recommend.

Cheers
The other James

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Thursday, 27 July 2006 1:28 PM
To: Winterbottom, James; Abbott, Nadine B; Brian Rosen; [email-masked]
Cc: [email-masked]
Subject: 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?

---

From: Andrew Newton <[email-masked]>
Date: Thu, 27 Jul 2006 08:32:54 -0400

> It sounds pretty definitive to these ears...

I don't believe working group chairs are given any special powers  
that such a decision is in their hands.  Any individual participant  
can approach an AD or the IESG either informally or via appeal about  
attempts to work around working group consensus.  Such things are  
taken seriously by the IESG, to the point that they can stop the  
publication of an RFC sent directly to the RFC Editor on this basis.

-andy

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 27 Jul 2006 13:06:15 -0500

At 08:32 AM 7/27/2006 -0400, Andrew Newton wrote:

>that such a decision is in their hands.

fair - but Brian asked for WG chair guidance because several points were 
churning over and over again (perhaps at Layer 8 - Religious), and I was 
asking if this view could be taken as WG chair guidance?

>Any individual participant