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

["James M. Polk" <[e-mail]>]

Robert

Thanks for the scrubbing.

These will be part of the post WGLC version.

James

At 02:45 PM 3/9/2011, Robert Sparks wrote:
>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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
>
>_______________________________________________
>sipcore mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/sipcore