Re: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance

There are a couple of larger and several small things to also address in this document before requesting publication.

The larger things:

1) In section 4.4, the document talks about providing a text string "RECOMMENDED for human readability". The document
needs to be clear who this is intended for. Do you expect this to be rendered to a user or only read by an operator?
(Fortunately quoted-string allows non-ascii UTF-8 already, so we won't have to argue about whether this needs to be
internationalized.)

2) The Geolocation-Error ABNF and the IANA registration section use a parameter name = value form (with a name of "code").
Following those sections of the document, the examples should all look like
Geolocation-Error: 100;code="Cannot Process Location"
But all the examples currently look like
Geolocation-Error: 100 "Cannot Process Location"

It's worth pointing out that 3261 (see the top of page 32) doesn't allow the same parameter name to appear in
a header field value more than once, so the following is not allowed:
Geolocation-Error: 100;code="Cannot Process Location";code="Impossible de processus de localisation"

Are the values you are registering for code= suggested defaults (like for SIP response start lines) or are
they what MUST appear? Is this OK?
Geolocation-Error: 100;code="Have a nice day"
If not, what in the document says so?

3) I can't figure out what the paragraph in section 4.4 that starts "Additionally, if a sip entity cannot..." and goes
onto talk about 503's is trying to say. I think some surrounding context must have been lost or not captured.
Why would we be recommending sending a 503 here?

4) Section 4.4 defines classes of error codes, and even default values of error codes, but does not go on to say
that if an element receives an error code it doesn't understand, it treats it like the default code in that class.
Surely that was the intent (otherwise, having the classes isn't particularly useful). If it was, the document should
say so.

---------------------------------------------------------

Here are the smaller things.
I've listed these in as close to document order as I could

1) In 4.1, please call out what document's definition of HCOLON, COMMA, LAQUOT, RAQUOT and SEMI that you are using.
    Either call out that these are used in other places in the doc (4.2 and 4.4) or similarly call out the terminals used in those
    sections (be sure to catch DIGIT and EQUAL in 4.4).

2) In section 4.1, I suggest replacing
OLD: A Geolocation header field MUST have at least one header-value.
with
NEW: A Geolocation header field MUST have at least on

3) In 4.2, I suggest replacing
OLD: Values other than "yes" or "no" are permitted as a mechanism for future extensions, and should be treated the same as "no".
with
NEW: The syntax allows values other than "yes" or "no" to appear to allow for future extensions. Implementations not aware of an extension SHOULD treat any other received value the same as "no".

I also propose that this be MUST instead of SHOULD.

4) 4.2.1, first paragraph, s/contained in a one or/contained in one or/ (delete the spurious "a")

5)  I suggest the following replacement for the paragraph in section 4.3 that starts "It is only appropriate"

It is only appropriate to generate a 424 response when the responding entity needs a locationValue
and there are no values in the request that are usable by the responder, or when the responder has
additional location information to provide. The latter case is shown in Figure 4 of section 3.4. There,
a SIP intermediary is informing the upstream UA which location to include in the next SIP request.

6) In 4.4 was "any SIP non-100 response" intended to mean
   a) any SIP response, including provisional responses other than 100 Trying
   or
   b) only SIP Final responses
   ? 

7) Section 8.1 claims two actions for IANA, but provides only one.

8) In section 8.5 step 2, please just say "Yes" under predefined values instead of "yes*", and
delete the footnote. Section 8.6 is the next section and is easy to find, and it will save
IANA having to ask if you are trying to put a * in the table in the registry.

9) A.2 UAS-1 will cause confusion. We are allowing locations to appear in responses, just not
    the location of the responder. Please adjust it to avoid that potential confusion.

    As an individual contributor, I don't think these appendices add enough value to the document 
    to warrant the confusion they may cause and would be happier if they were deleted.

On Feb 28, 2011, at 5:38 PM, Adam Roach - SIPCORE Chair wrote:

> [as chair]
> 
> The current editor of draft-ietf-sipcore-location-conveyance believes that the document has no remaining technical issues[1], and is ready for evaluation. Today, we are starting a two-week working group last call period. This last call period ends on Tuesday, March 15th.
> 
> The latest version of the document can be retrieved here:
> 
> http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance
> 
> Any comments on the document should be sent to the SIPCORE mailing list.
> 
> /a
> 
> [1] John Elwell's editorial comments of February 25th have been noted by the authors, and will be treated as WGLC comments.
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore