Subject: [Sip] How Location Conveyance specifies the allowed URI

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 27 Jul 2006 17:04:03 -0400

Trying, trying, ....

It seems we have a very rough consensus that there will be some
normative text that specifies the allowable URI schemes for what can be
in the location header.  There are still some voices in opposition to
it, but I think we've heard all the relevant points we're going to get.
I had made a specific proposal on this:

location-param = LAQUOT allowed-URI RAQUOT *( SEMI loc-param ) 
;cid-url from RFC2111, http_URL from RFC2616, SIP/SIPS-URI from RFC3261,
PRES-URI from RFC3859 
allowed-URI = cid-uri / http_URL / https_URL / SIP-URI / SIPS-URI
              / PRES-URI

As we seem to be developing another rough consensus on NOT defining an
HTTP dereference mechanism IN THE LOCATION-CONVEYANCE DOCUMENT, this
would now be:
location-param = LAQUOT allowed-URI RAQUOT *( SEMI loc-param ) 
;cid-url from RFC2111, SIP/SIPS-URI from RFC3261, PRES-URI from RFC3859 
allowed-URI = cid-uri / SIP-URI / SIPS-URI / PRES-URI

The text would say extensions to this list is by (?standards-track?) RFC
requiring geopriv review as a "using" protocol, but is not a SIP change.

A hypothetical http dereference RFC would have the following ABNF:
;allowed-URI from <location-conveyance>, http_URL from RFC2616
allowed-URI =/ http_URL / https_URL

The alternative is to use "AbsoluteURI", and to say roughly the same
thing about RFCs and geopriv review.  I prefer being explicit.  The "=/"
construction is very simple and very explicit. 

Can we accept this "allowed-URI" proposal and move on? Does it have to
be standards track, or is Informational okay?  I would think
informational is okay, provided geopriv reviews.  For example, if some
other organization came along and defined a protocol that worked, and
met the geopriv requirements, an informational saying that the way you
use this with SIP Location is blah, blah, blah, I would think, provided
geopriv agreed it met their concerns, that would be okay (even with the
ABNF extension to allowed-URI in the Informational) 

Brian

_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Jul 2006 17:10:00 -0400

If HTTP and other mechanisms are not defined in the draft (with which I 
agree), I see no technical reason not to allow other URI schemes in the 
draft ABNF.

At least from the voices I heard, my proposal of not restricting the URI 
scheme has received at least as much support as countervailing 
proposals, so I don't know now how you're counting rough consensus. Or 
are there supervotes?

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 27 Jul 2006 17:45:19 -0400

I don't claim there is a consensus on how the protocols are limited, only
that they are.  I don't think you are arguing that to put a URI in the
Location Header makes it a protocol needing geopriv review ("using protocol"
notwithstanding the wording problems).  The text would have to say that,
wouldn't you agree?

The net effect is the same, you can't use any URI in the header, it has to
be a protocol that has had geopriv review as a using protocol in an RFC.

I stated why I think the allowed-URI construction is better; it makes the
grammar precise and explicit.  AbsoluteURI makes the grammar imprecise and
implicit.

What is wrong with what I proposed, and what makes no ABNF restrictions
(absoluteURI) better?  Using absoluteURI means that the using protocol RFC
wouldn't have to have the one line ABNF extension to allowed-URI.  Is that a
benefit?  Is there any other difference?

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, July 27, 2006 5:10 PM
> To: Rosen, Brian
> Cc: IETF SIP List; GEOPRIV
> Subject: [Sip] Re: [Geopriv] How Location Conveyance specifies the
> allowedURI
>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 27 Jul 2006 17:45:19 -0400

Brian