Subject: [Geopriv] [Fwd: RE: [Sip] Allowing sip: (or prez:) in the location header]

From: Andrew Newton <[email-masked]>
Date: Thu, 20 Jul 2006 12:50:34 -0400

So that people stay informed if not on SIP list.

-andy

-------- Original Message --------
Subject: RE: [Sip] Allowing sip: (or prez:) in the location header
Date: Thu, 20 Jul 2006 12:19:27 -0400
From: Brian Rosen <[email-masked]>
To: 'Thomson, Martin' <[email-masked]>, [email-masked]

There is a point to limiting what can be sent in the Location header to
specific protocols which has received adequate review in both sip and
geopriv.

So, here is my concrete proposal:
Location       = "Location" HCOLON location-param *(COMMA location-param)
location-param = LAQUOT allowed-scheme HCOLON ":" ( hier-part / opaque-part
) RAQUOT *( SEMI loc-param ) ; hier-part and opaque-part from 3261
allowed-scheme = 'cid' / 'http' / 'https' / 'sip' / 'sips' / 'prez'
loc-param      = 'location-dereference-protocol=' deref-protocol /
generic-param
deref-protocol = token

allowed-scheme may be extended by a standards-track RFC.  Such an extension
is NOT considered a SIP extension and is NOT subject to the process defined
by RFC3427.  Corresponding resolution processes for such schemes MUST be
included in the RFC, and MAY be subject to review against RFC3693.

This document (in Section ?) defines a new IANA registry for deref-protocol,
and populates it with one initial value, 'rawGET'.  rawGET indicates that
the location reference may be dereferenced by sending a GET with no
parameters on the URI, using HTTPS (except in the emergency case, where HTTP
is permitted), and expects to receive one PIDF-LO document (with a MIME-type
of "application/pidf+xml")in response.  deref-protocol MUST be included if
the scheme is HTTPS (or HTTP in the emergency case).  Other schemes may or
may not require deref-protocol.  A standards-track RFC is required to add a
value to the registry.

If allowed-scheme is 'sip', 'sips', or 'prez', the location-param MUST
resolve to a presence service, which accepts a presence subscription request
per RFC3856 for the URI.  deref-protocol is NOT required.

Brian

> -----Original Message-----
> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Wednesday, July 19, 2006 8:33 PM
> To: Brian Rosen; [email-masked]
> Subject: RE: [Sip] Allowing sip: (or prez:) in the location header
> 
> There is a difference between using ABNF to limit what is possible and
> providing a baseline for implementations.
> 
> I was happy with the original proposal.  That is, define the header to
> include AbsoluteURI and say that implementations MUST implement https and
> cid.  I had assumed that the https derefence would be as simple as the
> dereference method for the following: <https://ietf.org/>.  Extra
> functionality/flexibility in dereferencing will actually be useful in some
> cases.
> 
> So here is my concrete proposal:
> 
> The ABNF defines a location URI as the following:
> 
> Location       = "Location" HCOLON location-param *(COMMA location-param)
> location-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )
> 
> This is a copy and paste of the Alert-Info header ABNF from RFC 3261.
> This follows the principle of least surprise.
> 
> Then we have text that says something to this effect:
> 
>   "Implementations MUST support the cid: URL [ref] for location by-value
> and the https: URL [ref] for location by-reference.  The https: URI MUST
> be accessible using an HTTP GET method.  Any URI that is included in this
> header MUST dereference to a PIDF-LO document (with a MIME-type of
> "application/pidf+xml")."
> 
>   "Parameters MAY be included to indicate additional features of the URI;
> for instance, with an https: URI, parameters could indicate that a POST to
> the URI with a request body provides the requester additional control over
> the information.  However, the requester MUST be able to use an HTTP GET
> request if this additional functionality is not supported."
> 
> You can then setup a registry for parameters with IANA, following the
> standard form for those things.  I will let the SIP folks make the call on
> avoiding 3427 process, but it's not a bad idea.1
> 
> Cheers,
> Martin
> 
> > -----Original Message-----
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Thursday, 20 July 2006 10:02 AM
> > To: Thomson, Martin; [email-masked]
> > Subject: RE: [Sip] Allowing sip: (or prez:) in the location header
> >
> > I think we are going to be explicit about what is allowed to be in the
> > Location header, and not use AbsoluteURI.  We think something DOES have
> to
> > document every possible retrieval mechanism and discuss the geopriv
> > privacy
> > issues and how they are dealt with.  That is precisely what we propose.
> > We'll define some of them in location-conveyance, and specify how a
> > standards track document adds more possibilities.
> >
> > Please note that we don't want a lot of possibilities here; every
> > dereferencer has to implement all choices.
> >
> > Incidentally, I think we will specify in the language that an extension
> to
> > the allowed URIs in a Location header is NOT a SIP extension, and does
> not
> > come under the 3427 process.   This would allow geopriv, for example, to
> > define the L7 protocol, and if it has a location-by-reference
> construction
> > with a dereferencing procedure, it would be allowed to add to the
> methods
> > listed in location-conveyance without running through 3427.  That
> > language,
> > since it is part of sip-location, would have to be acceptable to
> > sip/sipping.
> >
> > Agree that the identity issues of URL construction are generic and can
> be
> > treated in the text as generic, not tied to any particular scheme.  It
> may
> > be more likely in prez:, simply because the default type of uri is an
> AoR,
> > which almost always has identity data.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Thomson, Martin [mailto:[email-masked]]
> > > Sent: Wednesday, July 19, 2006 7:36 PM
> > > To: Brian Rosen; [email-masked]
> > > Subject: RE: [Sip] Allowing sip: (or prez:) in the location header
> > >
> > > Brian,
> > >
> > > Yes, you can use a sip: or pres: URI to retrieve location by-
> reference.
> > > It works.  Yes, you can use a pull method to retrieve the information;
> > > that's a feature of SUBSCRIBE/NOTIFY.  I see no reason to prevent
> this,
> > > but you don't actually have to document every possible retrieval
> method.
> > >
> > > Identity might be a problem, but that can be addressed by the use of
> > > unlinked pseudonyms.  This is not specific to the dereference method.
> > The
> > > same problem exists no matter how you resolve location - or are you
> > > suggesting that the sip: or pres: URIs dereference to a PIDF-LO, but
> > other
> > > forms would not?  Clearly, that problem already exists with the cid:
> URL
> > > and should exist with the https: URL.
> > >
> > > What I take from this is that you need to have text that explains the
> > > impact of the association between identity and location.  Those
> concerns
> > > are largely covered by other GEOPRIV documents, but there is no harm
> in
> > > being explicit.
> > >
> > > Cheers,
> > > Martin
> > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [mailto:[email-masked]]
> > > > Sent: Thursday, 20 July 2006 8:46 AM
> > > > To: [email-masked]
> > > > Subject: [Sip] Allowing sip: (or prez:) in the location header
> > > >
> > > > Suppose we allowed sip: or prez: as the location header URI.  The
> > > > resolution
> > > > of this scheme would be "subscribe to presence".
> > > >
> > > > Note that if you asked for immediate expiration (0), you will get
> the
> > > > immediate NOTIFY.  This constitutes one reasonable way to provide
> > > > location-by-reference.  It is a form of "pull" (you send a
> SUBSCRIBE,
> > > you
> > > > get one NOTIFY in return with the PIDF-LO).  If your subscription
> has
> > a
> > > > longer expiration, it is a form of "push", and you might want to
> have
> > a
> > > > filter to limit how many pushes you get.
> > > >
> > > > Note that normally, presence provides identity as well as location.
> > It
> > > > may
> > > > be that in some uses for the Location header, such as a location
> based
> > > > routing, the identity information is not appropriate.  The policy of
> > the
> > > > presence server for that use may be to only return the LO part of
> the
> > > > PIDF.
> > > > Also note that the form of the URI itself could inadvertently
> provide
> > > > identity information (prez:[email-masked]), which might not
> > be
> > > > desirable.  If the idea to allow sip: and prez: is acceptable in the
> > > > Location header URI, the text would contain a discussion of this
> > issue.
> > > >
> > > > 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
> > >
> > > ----------------------------------------------------------------------
> --
> > --
> > > ----------------------
> > > 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]
> >
> 
> --------------------------------------------------------------------------
> ----------------------
> 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]

_______________________________________________
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

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