Subject: Re: [Geopriv] How Location Conveyance specifies the allowed URI

From: "James M. Polk" <[email-masked]>
Date: Thu, 27 Jul 2006 16:20:44 -0500

At 05:04 PM 7/27/2006 -0400, Rosen, Brian wrote:
>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

I think the proper cid reference is RFC 2392

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

A vote for Standards Track, as this ensures IETF LC for everyone's chance 
at a proposal., also so some other WG doesn't attempt to slip something by 
anyone (meaning "by Geopriv")

>I would think
>informational is okay, provided geopriv reviews.

But I don't believe we can state who the reviewers are, we're limited to 
the type of RFC (if one is required)

>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
>
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

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

>anyone (meaning "by Geopriv")

As a WG chair, I should know this off the top of my head, but I'm 
bewildered by some of the comments here (and in another area), therefore 
confused...

I believe that each subsequent schema proposed would be an official 
'update' to this SIP RFC (to be), which is Standards Track, meaning I don't 
believe an INFO RFC can officially 'update' a Standards Track RFC.  This 
would mean updating this RFC (to be) would take a Standards Track RFC, if 
my math is right...