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

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Fri, 21 Jul 2006 15:12:28 +0200

(As individual)

In this discussion it is probably worth remembering the endpoint we are
trying to get to.

There should be a limitation on the number of protocols specified
because:

-	the consumer of the location header needs to support all the
protocols indicated in order to fetch the location. In the case of
emergency calls that must happen first time, i.e. without sending the
424 response code back to the UAC, and getting a new request containing
a new location header with a new URI which we then might support.

-	GEOPRIV wants to maintain supervision of all GEOPRIV using
protocols in order to ensure the privacy requirements are met, and
remember, such privacy requirements are only overridable in certain
jurisdictions for emergency call, not necessarily in all jurisdictions.
Therefore any potential extension is going to need GEOPRIV WG decision.

Therefore any extension to such a list is going to be "RFC required" or
possibly even "standards track RFC required". Therefore both precise
ABNF and RFC 2119 text can be updated by such an RFC, and we just need
to decide which one presents the clearer requirement to the reader, both
in its original form, and in any later potential updates RFC that
modifies the location-conveyance RFC.

Regards

Keith

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: 21 July 2006 01:43
> To: 'Thomson, Martin'; 'Jeroen van Bemmel'; 'Andrew Newton'
> Cc: [email-masked]
> Subject: RE: [Sip] Allowing sip: (or prez:) in the location header
> 
> We're dealing with a couple of issues here, so I'll take them 
> one at a time.
> 
> There is precedent for ABNF precise, and precedent for text 
> explanations.  I can tell you from long experience that 
> precise ABNF produces more interoperable implementations.  
> We're forever correcting people that the ABNF is not 
> definitive, and the text restricts what you can do.  If the 
> ABNF gets out of hand, then we often take short cuts using 
> normative text.  I'd prefer to avoid that.
> 
> I think it's inescapable that we are creating a precise list 
> of protocols, and prohibiting that which is not explicitly 
> allowed.  I don't see you arguing against that, just how it's 
> represented in the document.
> 
> Generally, I think the parameter and registry is a better 
> solution than squandering the GET method for a no parameter 
> resolution.  It works, and it's not terrible, but I think 
> explicitly stating the resolution protocol is much clearer.  
> I have another thought on that whole subject, but that will 
> wait for another email.
> 
> I think the text says "HTTPS must be used, except for the 
> emergency case".
> I don't think the draft needs to talk about HTTP headers for 
> the simple GET case, which is all we allow.  I think 
> authentication and cipher suites must be covered for all TLS 
> uses alike, so no sweat there.
> 
> Brian
> 
> > -----Original Message-----
> > From: Thomson, Martin [mailto:[email-masked]]
> > Sent: Thursday, July 20, 2006 7:45 PM
> > To: Brian Rosen; Jeroen van Bemmel; Andrew Newton
> > Cc: [email-masked]
> > Subject: RE: [Sip] Allowing sip: (or prez:) in the location header
> > 
> > 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/
> > 
> > > -----Original Message-----
> > > 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]
> > > Subject: RE: [Sip] Allowing sip: (or prez:) in the location header
> > >
> > > 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
> > >
> > > > -----Original Message-----
> > > > 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,
> > > >
> > > > >> 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.
> > > >
> > > > 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
> > >
> > 
> > 
> ----------------------------------------------------------------------
> > ----
> > ----------------------
> > 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
> 

_______________________________________________
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