Subject: [core] Ted Lemon's No Objection on draft-ietf-core-coap-15: (with COMMENT)

From: "Ted Lemon" <[email-masked]>
Date: Wed, 24 Apr 2013 20:32:26 -0700

Ted Lemon has entered the following ballot position for
draft-ietf-core-coap-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

P. 14: informative reference to HHGTG almost, but not entirely,
helpful.  :)

P. 15: why start at version 1 when you can only have a total of 4
versions?   Wouldn't version 0 be a better choice?

P. 19: I'm a little uncomfortable with this text:

	     There is no
             expectation and no need to perform normalization within a
             CoAP implementation (except where Unicode strings that are
             not known to be normalized are imported from sources
             outside the CoAP protocol).

I think what's intended here is right, but you've mentioned what
amounts to a strong suggestion, if not a requirement, as a
parenthetical note.  It seems like what you intended was something
like this:

	     There is no expectation and no need to perform
             normalization within a CoAP implementation, since senders
             are expected to be implemented with pre-normalized
             strings.  However, strings received from non-CoAP sources
             SHOULD be normalized where possible.

Of course, there's actually no value to normalization in this case if
it can't be depended on, and I suspect that you don't want to make
that a MUST.   So this might be a better way to do it:

	     There is no expectation and no need to perform
             normalization within a CoAP implementation, since senders
             are expected to be implemented with pre-normalized
             strings.  Strings received from non-CoAP sources and then
             forwarded by CoAP senders cannot be assumed to have been
             normalized, and may not compare correctly with normalized
             strings representing the same text.

I don't have a strong opinion about how this should be done, but it
seems like the text as written doesn't give clear guidance.  It seems
that cross-proxies ought to be able to do normalization, and maybe
other proxies could as well, but that's a much bigger change.

Section 4.1: Even though I think it doesn't make any sense to do this,
it might be worth stating how a receiver should behave if it receives
an ACK with a request.

Section 4.2: Wouldn't this:

   More
   generally, Acknowledgement and Reset messages MUST NOT elicit any
   Acknowledgement or Reset message from their recipient.

be better stated this way?

   More generally, recipients of Acknowledgement and Reset messages
   MUST NOT respond with either Acknowledgement or Reset messages.

Might be worth grouping for operator precedence here:

OLD:
         ACK_TIMEOUT * (2 ** MAX_RETRANSMIT - 1) * ACK_RANDOM_FACTOR
NEW:
         ACK_TIMEOUT * (2 ** (MAX_RETRANSMIT - 1)) * ACK_RANDOM_FACTOR

OLD:
         2 * MAX_LATENCY + PROCESSING_DELAY
NEW:
         (2 * MAX_LATENCY) + PROCESSING_DELAY

Section 5.8: The use of the word "safe" to describe methods is really
confusing because of save/unsafe options.  It would help ease of
comprehension if you used a different word--e.g., read-only.  I
realize that this goes somewhat against the idea of sharing
nomenclature with HTTP, but I think the clash between safe/unsafe
options and safe/unsafe methods is confusing enough that you aren't
really benefiting from that anyway.

In 5.9: as a user and implementor of RESTful systems who has learned
by doing more than by reading, the term "action result" is somewhat
opaque to me.  I think I know what it means, but it might be nice to
explain what it means before using it like this:

   Like HTTP 201 "Created", but only used in response to POST and PUT
   requests.  The payload returned with the response, if any, is a
   representation of the action result.

5.9.2.2: I think you mean "first" rather than "previously":

   The client is not authorized to perform the requested action.  The
   client SHOULD NOT repeat the request without previously improving its
   authentication status to the server.  Which specific mechanism can be
   used for this is outside this document's scope; see also Section 9.

5.10.1: how does the client know that an endpoint hosts multiple
virtual servers in time to leave out the Uri-Host option?  Is this
literally just in the case where the hostname appears in the URI to be
decomposed as an IP address literal?

   are sufficient for requests to most servers.  Explicit Uri-Host and
   Uri-Port Options are typically used when an endpoint hosts multiple
   virtual servers.

In 5.10.8.2: I can't quite understand what is meant here.  I could see
it meaning either or both of the following:

   1. If If-None-Match appears in a query with one or more If-Match
   options, and none of the If-Match options match, the condition is
   fulfilled.
   2. If If-None-Match appears in a query, no If-Match options may
   appear in that query; the condition is met if the target doesn't
   exist.

I think that the text means just (2), but because of the name of the
option, I want it to mean (1), even though the text doesn't say that,
and since the text doesn't say that If-None-Match and If-Match are
mutually exclusive, I can easily imagine someone reading the text and
carelessly assuming that it means (1) or (1 or 2).

In 6.4, why /url/?  This is really confusing--I was halfway through
this section, and kind of confused, before I realized that the slashes
were for emphasis, and weren't path separators.

Also in 6.4, the text does not account for the case where there's a
user part to the authority section of the URI.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 29 Apr 2013 16:52:24 +0200

Ted,

thank you for this review.
I have done some of the changes as simple editorial fixes, these are
marked like [1330] below and can be reviewed in
http://trac.tools.ietf.org/wg/core/trac/changeset/1330
(Overview in http://trac.tools.ietf.org/wg/core/trac/timeline).

Some of the replies are marked "-> Ticket": This means that the
authors think that the change is a good idea, but probably needs a bit
more discussion with the WG, so we will handle this as a ticket.

Grüße, Carsten

The authors continue to believe that the quote describes the
relationship between HTTP and CoAP in the most elucidating way...

(See my response to Richard Barnes.)

                     There is no

Unicode normalization is always a sticky point.  I think the choice of
a point on the continuum between your suggestions (which I both like)
needs to be discussed with the WG.
-> Ticket.

4.2 says: "The
   Acknowledgement message MUST echo the Message ID of the Confirmable
   message, and MUST carry a response or be empty (see Section 5.2.1 and
   Section 5.2.2).  [Sentence about RST.]
   Rejecting an Acknowledgement
   or Reset message is effected by silently ignoring it."
OK, that may not be as explicit as we thought: [1330]

          More

Indeed: [1330]

        OLD:

We actually mean:
                ACK_TIMEOUT * ((2 ** MAX_RETRANSMIT) - 1) * ACK_RANDOM_FACTOR

        OLD:

Both are done in [1331]

Safe methods is a rather established piece of REST terminology.
I'd rather rename the safe options.
"safe" here is an abbreviation for "safe-to-forward-in-a-proxy-while-not-understanding-them".
My thesaurus is of no use ... (well, it does suggest "hairy" for
unsafe. hairy and bald?)

5.5.1 introduces the concept, but without putting "action" and
"result" beside each other.  Added that.
[1332]

[1333]

Indeed, the Uri-Host option can use its default value only when the
URI has an IP address literal.

That is not what we mean.  If-None-Match is not meant to be combined
with If-Match.

Yes.

I clarified this somewhat. [1334]

It is hard to provide emphasis for variable names for pseudo-code in
an ASCII-only document.
I replaced the slahes by vertical bars, knowing well that this might
offend mathematicians. [1335]

It is not meant to.
This could never occur until we introduced Proxy-Scheme; we need to
add text that the use of Proxy-Scheme is not possible in this case.
-> Ticket

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 Apr 2013 16:55:05 +0000

> My thesaurus is of no use ... (well, it does suggest "hairy" for

Well, I have to admit that there is a certain poetry to hairy/bald, but it may be that some readers would find it odd.   Perhaps clear/active?   Or inattentive/attentive?   Or optional-to-interpret (oti)/must-interpret (mi)?   Like you, I have nothing good to suggest, but I think this is the right change to make.
> URI has an IP address literal.

It might be worth saying this.   I think a deep think about the document will make this clear to the reader, but it's always better if you can help them to avoid having to do the deep think if it doesn't have useful side effects.

> offend mathematicians. [1335]

That works for me.   The mathematicians will enjoy kicking up a fuss about it, so I think it's okay for everyone.

Thanks for considering these changes!