Subject: [Sip] WGLC comments on draft-ietf-sip-location-conveyance-13

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 31 Mar 2009 22:03:45 -0500

I've included my last call comments on sip-location-conveyance.  Unfortunately, this is a lengthy email.

The bulk of my comments are minor.  The abstract, which is quite concise, belies the enormous size of this document.  I, like Hannes before me, believe that this could be written for more succinctly than it is.

However, I am also of the opinion that we've been sitting on this document for too long.  Perhaps this document exemplifies the RAI woes.  It needs to be published, and I have very few substantial concerns with the technical content of the document.  At this stage, I would rather have a poor document published than have to wait another year for a good document.

However, the items I've identified as issues need to be addressed.

==Issue: Articulate Geolocation header semantics

The most important thing that this document needs to define is the semantics of the Geolocation header.  Section 3 gets straight into the "how", but never actually clearly states what the header means.  A UA is supposed to infer _something_ from the presence of a Geolocation header.  The semantics are unstated, which could lead to confusion.  

The problem is compounded in Section 6.1 when the document talks about location information for multiple targets in the one request.

Text along the lines of the following is necessary:

  "The Geolocation header indicates a resource that includes the physical location of the UA indicated in the From: header of the message."

Of course, this statement is both incorrect and incomplete.  You need to consider each of the SIP requests to arrive at a general framework for understanding the semantics of the header.  As it stands, the document provides no basis for determining what the semantics of the header are in, for instance, an INFO request.

Further to this, the use of Geolocation in a NOTIFY request needs to be made very clear.  NOTIFY in presence has well established semantics.  In many respects, Geolocation is not necessary for NOTIFY, particularly if it means that there are special cases required in establishing a common semantic for the header.

On the same issue, the following statement could be addressed for PUBLISH, but is avoided with some decidedly weaselly words:

   Discussing location using the PUBLISH request is out of scope
   for this document since it is part of Presence, therefore, for
   completeness, Table 1 shows PUBLISH is to support Location
   Conveyance via this extension, but is not discussed further.

Further related, I think that there are unstated assumptions about use of the entity attribute of the PIDF document.  I don't think that this appropriately considers the possibility that the PIDF could contain an unlinked pseudonym:

   However, if location is already in a SIP request, a SIP server
   SHOULD NOT add another LbyR that identifies the same target in the
   PIDF-LO (in the <dm:device id> element) to the same request.  This
   will likely cause confusion at the Location Recipient as to which to
   use.

I have been operating on the assumption that the binding of location to identity was done in SIP.  I can follow up with use cases and include more discussion as necessary.

==Issue: What does Geolocation-Error 500 mean

I don't understand this error code.

I don't think that I could successfully distinguish this from 1XX errors, despite the document claiming that the difference is simple (another value judgement).  It almost seems like a 4XX.

==Issue: Proxy insertion

I'd like to see the document answer this question:  If a UAC doesn't understand this document and the proxy inserts location for it, what behaviour is expected from both proxy and UAC if a 424 response is received?

The proxy consumes the Geolocation-Error header and determines that it needs to send again - but how does it do this?  Does it alter the error code to force the UAC to re-send the failed request?  If so, how does it determine that location is needed in the subsequent request?  Or, does this scenario always result in failure?

==Minor Technical Nits

Please reference RFC 3986 for URI ABNF.  Note also that all specific URI ABNF is a subset of the 3986 ABNF, so sip-URI, sips-URI, pres-URI and cid-url are redundant (yes, this comment has been made and ignored previously).

What benefit does the following restriction provide?
	
   Placement of the "routing-allowed" parameter, when
   present, MUST be the last header value in the Geolocation header.

Requiring positional significance on header parameters only leads to more complicated implementations.  If location can be inserted along the path, and that insertion must be at the end, insertion is quicker without having to first remove this parameter and re-add it after.

Also on "routing-allowed", why is presence or absence of the tag used to indicate yes and no, rather than requiring values?

Avoid making value-judgements, such as:

   #1 - SIP Servers are not the best Sighters

Suggest changing the Geolocation-Error "code" parameter to be "text" to make its usage clearer.  What about i18n concerns on this parameter; does it need language tags?

I don't have a means of interpreting Table 1 and Table 2.  There is no legend in RFC 3261.  I apologise for singling this document out, but I generally don't dig into SIP I-Ds in any great depth.  No doubt there is some unstated convention that is widely understood.

The examples still don't conform to RFC 5491.

Section 6.1: as established in geopriv-lbyr-requirements, an LS is the entity that serves a location URI.  Following on from that, the Location Generator isn't involved in control of any sort.

I can't see how the following statement makes sense:

   Use of self-signed certificates is inappropriate for use in
   protecting a PIDF, as the sender does not have a secure identity of
   the recipient.

Use (or not) of self-signed certificates generally leads to issues regarding trust anchors, so this statement almost makes sense.  However, I don't understand what protection is being sought here.  

If this statement is intended to address the issue where the UAC doesn't know the ultimate recipient of the request, then the issue is different.  In this case, the issue is relates to whether data can be encrypted for the recipient.

I don't think that 2119 language is appropriate for the following statement:

   The UAS is not REQUIRED to dereference the LbyR if
   it does not want to (by configuration or user choice).

The same goes for the statement that follow this.

Is this a recommendation by stealth?

   This document gives no guidance which SIP
   request to use, but SIP MESSAGE is a viable choice.

If MESSAGE is the right way to indicate location, then say it.  Or, don't make any recommendation.

On multiple locations:

   This document says nothing about what a Location Recipient does with
   more than one 'good' locationValue in a request (i.e., which to
   choose to use).  This scenario MAY be addressed in a future effort.

This isn't a hard problem to solve.  I don't see a need to defer this decision.  Pick an answer.  If it turns out to be the wrong one, then that's ok, the future effort can fix it.  Better to pick one and be wrong than leave it unspecified so that we get interoperability problems.

On the assumption that SIP is the only dereference protocol:

   A proxy wishing to dereference an LbyR URI contained in a received
   request will use the 'presence' event package in a SUBSCRIBE request
   to the URI.

With statements like this, there is little point in allowing other protocols.

Section 6.3.2 refers to a proxy being subject to all the rules of a UAS, and then references 6.2.1, which discusses geolocation-error generation:

   For proxies that receive a SIP request that contains a location
   error, either in a contained message body or after the proxy does a
   dereference of the LbyR URI, all the rules applicable to a UAS apply
   here  (see Section 6.2.1.), since in this case, the proxy is
   considered a Location Recipient. Therefore, there is no reason to
   restate them here, and potentially have the two sections be
   inconsistent.

This is confusing.  Does this relate to processing of the request?  Generation of the error (as implied by the reference).  Or is this a privacy thing (implied by the use of the GEOPRIV term of Location Recipient)?  If it does relate to consumption of location information and generation of 424 or Geolocation-Error headers, then it might make sense to put all information regarding this behaviour in a separate section.

The large paragraph on Section 8 Page 38 seems to be a rehash of the issues discussed in draft-ietf-geopriv-sip-lo-retransmission and draft-ietf-geopriv-lbyr-requirements.  As it stands, the discussion on the difficulties associated with deploying authentication are interesting, biased and not relevant for this document.  Better to add an informational reference and be done.

Small change to the following to allow for different authorization models:

   Accordingly, possession of the reference should be considered
   equivalent to possession of the value, and the reference should be
   treated with the same degree of care as the value.  

s/Accordingly/Unless a location reference is known to be public/

==Editorial

This document uses and invents terminology that is inconsistent with GEOPRIV documents.

This is a difficult document to read and review.  The longer sections lack structure and use very long paragraphs with lots of symbols, terminology and parenthetical statements.  

Avoid using ABNF names in text where English would suffice.  The weakness in using this approach is revealed when you pluralise these.  locationValue and locationErrorValue are used extensively in this manner.

Page 8: what makes the header parameters "independent"?  A roguish disposition with a natural disrespect for authority?

Some sections could really benefit from sub-sections.  The current document has a stream-of-consciousness quality that makes it difficult to quickly find relevant text.  At a minimum, sub-sections for each header parameter would be a great help.

A degree of bias is shown in Section 6.1, avoiding mention of HELD.  I'm demonstrating my own bias by making the comment, but I don't think that the comment is any less valid for it.

Section 5.1 contains text about location by reference that is redundant given the subject of Section 5.2.

--Martin

------------------------------------------------------------------------------------------------
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]