Subject: [Sip] Comments on draft-ietf-sip-location-conveyance-07

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Mon, 16 Apr 2007 17:43:11 +0200

In compiling the comments received so far, I came across a few of my
own:

Technical
---------

-	General: usage of Geolocation and location bodies in responses.
Obviously errors cannot be used in response to this, and location based
routeing at a proxy is inappropriate. If we are allowing location in
responses, we need to be clearer about which bit of the procedures
apply, and which do not. This should probably be specifically worked in
section 5.

-	Dialog Usage of new 424?

	RFC 4485 (http://www.ietf.org/rfc/rfc4485.txt) section 5
specifies:

   Dialog Usages: SIP allows for requests that normally create their own
      dialog (such as SUBSCRIBE) to be used within a dialog created by
      another method (such as INVITE).  In such a case, there are said
      to be multiple usages of that dialog.  Extensions SHOULD consider
      their interaction with dialog usages.  In particular, extensions
      that define new error response codes SHOULD describe whether that
      response code causes the dialog and all usages to terminate, or
      just a specific usage.

-	5, last 2 para:

   More than one location representation or format, for example: civic 
   and coordinate, MAY be included in the same message body part, but 
   all MUST point at the same position on the earth.  Multiple 
   representations allow the recipient to use the most convenient 
   representation of location.  

   There MAY be more than one PIDF-LO in the same SIP message, so long 
   as each is in a separate message body part. Each location body part 
   MAY point at different positions on the earth.  The meaning of such 
   a construction is not defined, and may cause confusion at the 
   recipient.

	I would prefer that this is separated into sender and receiver
requirements, and put into the appropriate subsections within section 5.
Need to sort out the RFC 2119 language when doing so.

Editorial
---------

-	1, 5th para:

   Often, location is sent from the User Agent Client to the User Agent
   Server, or vice versa for purposes that are beyond the scope of this
   document.  Another use for location is location-based routing of a 
   SIP request, where the choice of the next hop (and usually, the 
   outgoing Request URI) is determined by the location of the UAC which
   is in the message by-value or by-reference.  This document describes
   how location may be conveyed from the UAC, or a proxy acting on its 
   behalf, to a routing proxy.  How the location is actually used to 
   determine the next hop or Request-URI is beyond the scope of this 
   document.

	change "may" to "can".

-	1, 6th para:

   The Geolocation header is introduced to signify that location is 
   included in a SIP message to provide either a content identifier 
   (cid:) pointer to the body part containing the UA's PIDF-LO, or a 
   location-by-reference URI that may subsequently be "dereferenced" by 
   a using protocol (which may be SIP or another protocol).

	change "may" to "can".

-	1, last para:

   In this document, we frequently refer to the "emergency case".  This
   refers to a specific, important use of sip location conveyance where
   the location of the caller is used to determine which Public Safety 
   Answering Point (PSAP) should receive an emergency call request for 
   help (e.g. a call to 1-1-2 or 9-1-1).  This is an example of 
   location-based routing.  The location conveyed is also used by the 
   PSAP to dispatch first responders to the caller's location.  There 
   are special security considerations which make the emergency case 
   unique, compared to a normal location conveyance within SIP.

	change "should" to "is expected to" to avoid RFC 2119 type
language here.

-	3.1, 1st para:

   This document creates a new SIP header: Geolocation.  The 
   Geolocation header contains either a URI which may be a "cid:" URI 
   (Content Identification, per [RFC2392], or a location-by-reference 
   URI to be dereferenced by a location recipient to retrieve the 
   location of the UAC.

	Change "may" to "can".

-	3.1, 4th para:

   The Geolocation header, either with the PIDF-LO in a body or as a 
   location-by-reference URI, may be included by a User Agent in a 
   message.  A proxy server may assert location of the UA by inserting 
   the header, which must specify a location-by-reference URI.  Since 
   body parts may not be inserted by a proxy server, location-by-value 
   cannot be inserted by a proxy.

	Change "may" to "can".

-	3.1, 5th para:

   The Geolocation header may have parameters that are associated 
   with a URI in the header.  The "inserted-by" parameter has values of
   "endpoint" or "server", indicative of which entry added location to 
   the message. This header parameter MAY be added every time a new 
   location is added into a message.

	Change first "may" to "can". For the final sentence, I would
prefer this appeared elsewhere in the document as I would like to keep
RFC 2119 language out of a section entitied "overview".

-	3.4, 3rd para:

   The Warning header allows for multiple warning codes be returned in 
   the same response.  If a location-by-reference is sent and the 
   supplied scheme is not desired or cannot be processed, but more than
   one other scheme can be, the 424 response can list more than one 
   code from the 720-724 range in the response. The UAC may 
   subsequently retry the operation with one of the schemes supported 
   or desired by the recipient.

	Change "may" to "can".

-	3.4.1, 1st para:

   A Warning header with the code 701 "Location Format not supported" 
   means the location format supplied in the request, by-value or 
   by-reference, was not supported.  This cause means the recipient 
   understood that location was included in the message, but the format
   is not supported.  Perhaps the format was a freeform text format or 
   data-URL and the recipient only understood location in RFC 4119 
   PIDF-LO format (civic or coordinate). If a more specific Warning 
   code is available, it MUST be used.  For example, if the format is 
   understood, but not desired, a 702 or 703 Warning header should be 
   returned in a 424 response, depending on which location format is 
   desired. The same applies to a location recipient that only 
   understands one format and did not receive that format. For example,
   if a message containing coordinate formatted location arrives but 
   the recipient only can process civic formatted location, a 703 
   Warning header should be returned in a 424 response.

	Query RFC 2119 language on use of word "should". Is it or isn't
it. If it is not, change the wording to make clearer this is part of the
example. If it is not, then make clear that it is a normative
requirement by deleting "For example".

-	3.4.1, 4th para:

   A proxy server may assert location of the UA by inserting 
   the header, which must specify a location-by-reference URI.  Since 
   body parts may not be inserted by a proxy server, location-by-value 
   cannot be inserted by a proxy.

	"must" or "MUST". If the requirements are elsewhere use a
different word to "must".

	change "may not" to "cannot".

-	3.4.5, 1st para:

   A Warning header with the code 705 "Cannot find location" means 
   location should have been in the message received, but the recipient
   cannot find it, either because it is not in the message, or it is 
   encrypted/opaque to the recipient.  

	"should have been" --> "was expected".

-	3.4.12: There are two sections labelled such.

-	5, 1st para:

   Because a person's location is generally considered to be sensitive 
   in nature, privacy of the location information must be protected 
   when transmitting such information.  Section 26 of [RFC3261] defines
   the security functionality SIPS for transporting SIP messages with 
   either TLS or IPSec, and S/MIME for encrypting message bodies from 
   SIP intermediaries that would otherwise have access to reading the 
   clear-text bodies.  SIP endpoints SHOULD implement S/MIME to encrypt
   the PIDF-LO message body (part) end-to-end when the intended 
   recipient is the opposite UA.  The SIPS-URI from  [RFC3261] MUST be 
   implemented for message protection (message integrity and 
   confidentiality) and SHOULD be used when S/MIME is not used.  
   Possession of a dereferenceable location URI may be equivalent to 
   possession of the location information itself and thus TLS SHOULD be
   used when sending location-by-reference.  

	Change "may" to "can".

-	5.1, 1st para:

   A UAC may send location because it was requested to, to facilitate 
   location-based routing, or spontaneously (i.e. a purpose not defined
   in this document but known to the UAC).  A UAC MAY receive location 
   from the UAS spontaneously.  

	Change 1st "may" to "can".

-	5.1, 7th para:

   There MAY be future work defining additional error information, say 
   in an XML body, indicating exactly what the error was, if any of the
   new Warning codes are ambiguous.

	Inappropriate usage of RFC 2119 "MAY". Rewrite: "Additional
error information indicating more specifically what the error is are
outside the scope of this document, but could form the basis of future
work" - if we need to say anything at all - it would be perfectly
reasonable to delete this paragraph entirely.

-	5.3, 1st para:

   [RFC3261] states message bodies cannot be added by proxies.  
   However, a proxy may add a header to a message.  This implies that a
   proxy MAY add a geolocation header with location-by-reference, but 
   not location-by-value.

	Change 1st "may" to "can". The "MAY" is inappropriate here
following the word "implies". We have to have certainties about RFC 2119
language.

-	5.3, 3rd para:

   More than one Geolocation header or header value in a message is 
   permitted.  The meaning of such a construction is not defined, and 
   may cause confusion at the recipient.

	change "may" to "can".

-	5.3	4th para:

   Proxies that perform location-based routing may need to consult 
   external databases or systems to determine the route.  Transmission 
   of the location information (which SHOULD NOT reveal identity, even 
   if the proxy knows the identity) is governed by the 
   'retransmission-allowed' and 'routing-query-allowed': 

	change "may" to "can"

-	6, 3rd para:

   Recognizing which calls are emergency calls is beyond the scope of 
   this document.  When an emergency call is placed, location is 
   normally provided by the UAC.  Since emergency calls must be routed 
   based on location (and indeed, in some jurisdictions, there may be 
   several steps to such routing), the location must be visible to 
   proxies along the path.  Thus S/MIME protection of location MUST NOT
   be used.  TLS protection of location SHOULD be used, however, if 
   establishment of the TLS connection fails, the call set-up 
   operation, including location conveyance, MUST be retried without 
   TLS.

	Firstly emergency calls must be routed on location in some
countries only. Secondly avoid pseudo RFC 2119 language. Suggest "must"
--> "can". Change "may be" to "can be".

-	6, 5th para:

   Both the "retransmission-allowed" and "routing-query-allowed" SHOULD
   be set to "yes".  Querying for routing may be performed by proxies 
   providing a routing service for emergency calls even if 
   retransmission-allowed or routing-query-allowed is set to "no" or is
   not present.  Proxies routing on the location MUST set the 
   "message-routed-on-this-uri" parameter.

	change "may be" to "can be".

-	8, 1st para:

   Conveyance of physical location of a UAC raises privacy concerns, 
   and depending on use, there may be authentication and integrity 
   concerns.  This document calls for conveyance to normally be 
   accomplished through secure mechanisms (like S/MIME or TLS).  In 
   cases where a session set-up is routed based on the location of the 
   UAC initiating the session or SIP MESSAGE, securing the by-value 
   location with an end-to-end mechanism such as S/MIME is problematic,
   because one or more proxies on the path need the ability to read the
   information to route the message appropriately.  Securing the 
   location hop-by-hop, using TLS, protects the message from 
   eavesdropping and modification, but exposes the information to all 
   proxies on the path as well as the endpoint.  In most cases, the UAC
   does not know the identity of the proxy or proxies providing 
   location-based routing services, so that end to middle solutions may
   not be appropriate either.

	change 1st "may" to "can". Change "end to middle solutions may
not be appropriate either" to "end-to-middle solutions can also be
inappropriate".

_______________________________________________
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