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

From: Jeroen Van Bemmel <[email-masked]>
Date: Thu, 20 Jul 2006 19:02:45 +0200

Brian,

To me using ABNF rules to restrict allowable schemes is not a good idea. ABNF defines syntax, not semantics

Compare this with the Route header in SIP. The ABNF allows any scheme, text says it MUST be sip: or sips:. That suffices (you could define which error response must be sent)

Moreover, the protocol to use is a policy decision. You can make recommendations, even define new mechanisms, but I think the choice should be left to implementors

Regards,

Jeroen
-----Oorspronkelijk bericht -----
Van: "Brian Rosen" <[email-masked]>
Aan: "'Thomson, Martin'" <[email-masked]>; [email-masked]
Verzonden: 20-7-06 18:19
Onderwerp: RE: [Sip] Allowing sip: (or prez:) in the location header

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

_______________________________________________
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: Andrew Newton <[email-masked]>
Date: Thu, 20 Jul 2006 13:28:52 -0400

> Compare this with the Route header in SIP. The ABNF allows any scheme, text says it MUST be sip: or sips:. That suffices (you could define which error response must be sent)

I agree.  The same is also true for a lot of specs that use XML Schema 
but then use 2119 language on top of that.

> Moreover, the protocol to use is a policy decision. You can make recommendations, even define new mechanisms, but I think the choice should be left to implementors

I disagree with this.  What is my server gonna do with a mailto: or dns: 
URI?  There should be a small list of acceptable choices if we want 
interoperability.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 20 Jul 2006 13:28:52 -0400

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 20 Jul 2006 14:57:00 -0400

Jeroen

I don't agree that this is a semantic issue; we are restricting precisely
what may appear in allowed-scheme.  I usually think it's better to have the
ABNF precise, rather than relying on text to state what is actually
permitted on the wire.  We are talking about what is syntactically allowed,
not how you interpret it.

The ABNF =/ syntax (from RFC4234) is a convenient way to add a scheme to the
list, even when used by independently created RFCs.

I, like Andy, don't believe the decision on which protocols can appear in
allowed-scheme can be left to implementation.  Every dereferencer has to be
prepared to use every possible protocol, especially on the Internet, because
there is no way to ask for a specific URI or limit the schemes the location
acquisition mechanism may obtain.

Brian

> -----Original Message-----
> From: Jeroen Van Bemmel [mailto:[email-masked]]
> Sent: Thursday, July 20, 2006 1:03 PM
> To: Brian Rosen; 'Thomson, Martin'; [email-masked]
> Subject: RE: [Sip] Allowing sip: (or prez:) in the location header
> 
> Brian,
> 
> Compare this with the Route header in SIP. The ABNF allows any scheme,
> text says it MUST be sip: or sips:. That suffices (you could define which
> error response must be sent)
> 
> Moreover, the protocol to use is a policy decision. You can make
> recommendations, even define new mechanisms, but I think the choice should
> be left to implementors
> 
> Regards,
> 
> Jeroen

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 20 Jul 2006 22:31:15 +0200

Andrew,

>> recommendations, even define new mechanisms, but I think the choice 
>> should be left to implementors
>

In such a case your server should probably respond with "4xx Location URI 
Scheme not supported", where 4xx is TBD. However, if retrieving the location 
is not critical to completing the call, then it should probably ignore the 
header. So there seems to be a need for a parameter indicating "optional" 
versus "required"

IMO the text in the draft should say:
- proxies MUST support HTTP, SHOULD support HTTPS, MAY support cid (for 
dereferencing)
- UAS MUST support HTTP and cid, SHOULD support HTTPS (for dereferencing)
- TBD: define whether and when proxy/UAS should generate error for 
unsupported URI scheme (and then indicate which schemes are supported)
- UAC/Proxy SHOULD use HTTPS when adding Location by reference
- UAC MAY use cid for location by value, but SHOULD then ensure 
confidentiality

But above all: the draft should specify what is minimally needed to meet the 
stated requirements, while not unnecessarily restricting solutions that 
might have additional requirements which are not currently foreseen

Regards,

jeroen

---

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

I don't think you have the big picture.

Location comes from the access network, via some acquisition protocol, or in
some cases, can be self generated in the endpoint.   The access network
decides what the representation of the location is if it's supplying
location, although it may give an endpoint some options (value/reference,
civic/geo).

The UAC gets this location and puts it in the SIP message.

Some entity, could be a proxy for location based routing, or the UAS, gets
the location and does something with it.

For the sake of argument, assume its location-by-reference.
Call the proxy or UAS the "de-referencer".

It's the access network (could be a broadband carrier, could be an
enterprise) that is putting up the server that provides the de-reference
service.  Call the server a "Location Information Server" = LIS

Okay, so the access network chooses some protocol, makes up a suitable URI
and passes it via the acquisition protocol to the UAC.  The UAC passes it to
the de-referencer, who presents it to the LIS.  The LIS responds with the
location value.

The problem is that the de-referencer can't control which LIS, and can't
control what protocol decision the LIS made.  It has to implement EVERY ONE
of the protocols that could appear in the Location header.  If the LIS
implements a protocol the de-referencer doesn't understand, the whole
mechanism fails, with no recourse.  On the Internet, which is where we want
the protocols to work, you can't control which access network the UAC is
coming from.

So, instead, we restrict the list of allowed de-referencing protocols to a
small number, and make that list very explicit.  Now a de-referencer knows
that if he implements ALL of the listed protocols, he will be able to
dereference any location reference he gets.

There is another big picture aspect.  The whole location thing comes under
geopriv.  We have to do a sip Location header in sip, but geopriv has to
review our work.  The "priv" part of geopriv is privacy.  They care, a whole
lot, about the privacy aspects of location.  One expression of that concern
is to have the security posture of "what is not explicitly permitted is
prohibited".  They really truly want to look at every IETF protocol that is
used to de-reference location, and decide if it provides sufficient privacy
protection for location.  They really do want an explicit list, and they
want to scrutinize every protocol on that list to see how it addresses their
concerns.  SIP is what geopriv calls a "using protocol" and they review them
seriously.  This means, for example, that it's probably not okay to use HTTP
to de-reference.  There is a specific, limited exemption for emergency calls
on that.  So HTTPS is a MUST, and HTTP is MUST NOT except for the emergency
case.  I believe that "AbsoluteURI" would not be acceptable to geopriv, but
of course I can't speak for the group.

Brian

> From: Jeroen van Bemmel [mailto:[email-masked]]
> Sent: Thursday, July 20, 2006 4:31 PM
> To: Andrew Newton
> Cc: Brian Rosen; 'Thomson, Martin'; [email-masked]
> Subject: Re: [Sip] Allowing sip: (or prez:) in the location header
> 
> Andrew,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Jul 2006 19:28:10 -0400

Brian,

In general I could go with either a syntactic or semantic constraint. In 
general I think a syntactic constraint is preferred if it is possible, 
and the fallback to semantic constraint comes when the concept can't be 
represented precisely in the syntax, or is too cumbersome to do in practice.

But I am concerned with how you have tried to do this in syntax. What 
you have ended up with is a looser definition for a SIP URI than is 
present in 3261. That at least "smells a little funny".

If you want to do it in syntax, then I think you should enumerate the 
syntactic type of each kind of URI you want to permit. That still allows 
new ones to be added, but then at least each one will be properly 
constrained.

	Paul

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 20 Jul 2006 18:45:13 -0500

No, I think that Jeroen has exactly the right idea.  Restriction can exist at two levels, and in this case, text is the correct place for those choices.  I don't like to argue from precedent, but there is a clear precedent for this.

The issue of attaching additional parameters to a URI ("URI metadata") is a good one, and permits the use of value-add protocols.  But that should not affect the basic specification, it can remain optional.

This can be very simply specified: If the https: URI exists a raw GET MUST be possible.  An https: URI is widely understood, and I don't think that this behaviour is contradictory to any expectations.  The value-add protocols can be exercised by a POST, if the parameters indicate a specific protocol is supported and the requester understands the parameter and the protocol.  A GET should still be possible regardless.

You don't need to create a registry for protocols right now; let those protocol specifications (please, let there be only one) deal with that.

One problem with limiting as you have is that you have to be very clear in how each of those protocols are used.  Now, given Paul's comments, I think that sip[s] and pres need a little more info - do you want to include that as well?

Ultimately, I am arguing for a smaller location conveyance draft.  The problem with these discussions is that you can, effectively, refine indefinitely.  Do we start to discuss what authentication methods are appropriate in the HTTP GET?  What about HTTP headers?  How we deal with caching?  TLS cipher-suites?  I think that it's important to know when to draw the line.

Regards,
Martin

p.s... s/prez/pres/

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Friday, 21 July 2006 7:27 AM
> To: 'Jeroen van Bemmel'; 'Andrew Newton'
> Cc: Thomson, Martin; [email-masked]

------------------------------------------------------------------------------------------------
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: "Brian Rosen" <[email-masked]>
Date: Thu, 20 Jul 2006 20:20:06 -0400

Just to make sure I'm following you, the part you are unhappy with would be
the "heir-part / opaque-part" which is the definition of AbsoluteURI in
3261?  You would want me to define something that was closer to what each
URI scheme uses for what comes after the colon? 

So maybe:
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

Amusing side note on this.  I don't believe there is any actual definition
of an https_URL.

Brian

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, July 20, 2006 7:28 PM
> To: Brian Rosen
> Cc: 'Jeroen Van Bemmel'; 'Thomson, Martin'; [email-masked]
> >> To me using ABNF rules to restrict allowable schemes is not a good
> idea.
> >> ABNF defines syntax, not semantics
> >>
> >> is permitted), and expects to receive one PIDF-LO document (with a
> MIME-
> >> type
> >> may not require deref-protocol.  A standards-track RFC is required to
> add
> >> a
> >
> >

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 20 Jul 2006 23:18:38 -0500

My last email on the topic, I hope.

The below is fine, but I would like to point out that we are able to do some nice things with SIP because the authors saw fit to define the request URI as:

Request-URI    =  SIP-URI / SIPS-URI / absoluteURI

This has enabled the use of other values.  Think pres: and urn:service:.

I'd also like to point out that the above contains redundancies.  If we go by RFC 3986 definitions for absoluteURI (and we should, for new specifications), SIP-URI defines a subset of absoluteURI, therefore it is not required in that definition.

Cheers,
Martin

p.s. https: is very loosely defined in RFC 2818 according to the IANA URI scheme registry.

> Sent: Friday, 21 July 2006 10:20 AM
> To: 'Paul Kyzivat'
> Cc: 'Jeroen Van Bemmel'; Thomson, Martin; [email-masked]
> > > what may appear in allowed-scheme.  I usually think it's better to
> have
> > the
> > > The ABNF =/ syntax (from RFC4234) is a convenient way to add a scheme
> to
> > the
> > > allowed-scheme can be left to implementation.  Every dereferencer has
> to
> > be
> > >> location-param = LAQUOT allowed-scheme HCOLON ":" ( hier-part /
> opaque-
> > >> part
> > >> parameters on the URI, using HTTPS (except in the emergency case,
> where
> > >> HTTP
> > >> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jul 2006 09:28:15 -0400

> I don't think you have the big picture.

Nice explanation. More below.

> of course I can't speak for the group.

I fail to see how the exception could work in practice. How can the LIS 
know when it should accept an HTTP query and when it should not? What is 
to prevent somebody from changing an HTTPS URI to an HTTP URI and then 
dereferencing it?

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 21 Jul 2006 10:42:51 -0400

There are no protocol police.

There is nothing to stop it from doing so.
There is nothing to stop a server from not even implementing HTTPS.  They
seem to do it with sip TLS all the time.

All we can do is write the spec the right way, and ask the implementers to
please follow the spec.

This observation is one reason why we want the reference itself to be
protected in transit. 

Of course, mere possession of a location is not really useful.  You need to
be able to associate the location with some person (or thing).  The
reference, therefore, might want to be opaque, and you again want to protect
the signaling that would show an observer the relationship between an
identity and a location.

Brian

> Sent: Friday, July 21, 2006 9:28 AM
> To: Brian Rosen
> Cc: 'Jeroen van Bemmel'; 'Andrew Newton'; [email-masked]; 'Thomson, Martin'
> >> But above all: the draft should specify what is minimally needed to
> meet
> >> the