Subject: [Sip] Some comments for location-conveyance-08

From: <[email-masked]>
Date: Tue, 31 Jul 2007 10:50:38 +0300

Hi,

I had a review of draft-ietf-sip-location-conveyance-08 and
have the following comments to it. I have not followed up
the email discussions for this draft so please apologize
if any of my comments have already been raised.

1. Possible values within the inserted-by parameter

What kind of value should the UAC enter into the "inserted-by"
parameter if it does not have a hostname ? Is e.g. the local IP 
address of the UAC OK ?

The BNF syntax refers to "host-id" when describing the contents
of the "inserted-by" parameter. However I did not find anywhere
any formal BNF definition to the "host-id" (either in this draft
or RFC 3261), thus it is not clear if it only refers to a hostname
or could it also refer to e.g. an IP address or some other 
cryptographically constructed random ID allocated by the UAC.

2. Handling of 424 responses

In my opinion the handling the 424 responses is not well specified:

UAC: 

   The Geolocation-Error has a header parameter indicating which entity
   inserted the location pertaining to this error.  This is in the form
   of a host-id.  A UAC receiving this 424 should review this 
   "inserter=" locationErrorValue parameter to see if it indicates this
   UAC.  If it does not, the 424 should be ignored. 

First of all the Geolocation-Error header might contain multiple 
locationErrorValue entries. It is not clear in the normative text
for UAC that the UAC is expected to search through all of those to
check if it can find any entries targetted to itself. Further on
if there is no entries for the UAC, shall the UAC really ignore
the 424 and continue retransmitting the request or handle it as
4xx response and stop retransmissions ?

What if it was the proxy to insert Geolocation header into the
request and the UAS would return 424 response ? There is no 
normative text for the proxy to take this response into account
even if the Geolocation-Error header would refer to the proxy.

3. Usage of geolocation tag in the Supported header

Usage of the geolocation tag in the Supported header is not
specified according to the guidelines of RFC 3261. There were 
similar issues raised for SIP Outbound recently and the agreement
was to fix them:
http://www1.ietf.org/mail-archive/web/sip/current/msg20045.html

RFC 3261:

   If the UAC supports extensions to SIP that can be applied by the
   server to the response, the UAC SHOULD include a Supported header
   field in the request listing the option tags (Section 19.2) for those
   extensions.

draft-ietf-sip-location-conveyance-08:

   Whenever a UA wants to 
   indicate support for this SIP extension, the geolocation option tag 
   is included in a Supported header of the SIP message.  

   The UAC supporting this 
   extension MUST include a Supported header with the geolocation 
   option tag.

   The geolocation option-tag is inserted in a Supported header by a 
   UAC to provide an indication of support for this extension.  The 
   presence of the geolocation option tag in a Supported header without
   a Geolocation header field in the same message informs a receiving 
   SIP element the UAC understands this extension, but it does not know
   or wish to convey its location at this time.  Certain scenarios 
   exist (location-based retargeting) in which location is required in
   a SIP request in order to retarget the message properly.  This 
   affects how a UAS or SIP server processes to such a request.

The semantics of the geolocation tag within the Supported header seems
to be vaguely defined. The presence of this tag does not indicate the
UAS (or proxy) any extensions that the server could apply to its
response.
According to RFC 3261 that would however be the reason why to include an
option tag into the Supported header of a request. All the use cases
given in the draft for the geolocation tag justify its usage within
the Require header but there seems to be no clear reason why the UAC
would add it into the Supported header of a request. Support for the
extension can also be inferred from the presence of Geolocation header.
If it is not present but the a proxy would require it for retargeting, 
the correct behaviour would be the proxy to send 421 Extension Required
response.

   A UAS MAY include a geolocation option-tag in the Supported header 
   of a response, indicating if does understand this extension.

Similarily for the UAS no clear reasons exist why to include the 
Supported header into its response.  

Nit:

4.1 Location-by-value

   Geolocation: <cid:[email-masked]> 

   --boundary1

   Content-Type: application/pidf+xml
   Content-ID: [email-masked]

In Geolocation header the Content ID begins with "target123"
even if within the MIME entity the ID begins with "alice123".

Regards,

Erkki Koivusalo

_______________________________________________
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