Subject: [core] draft-ietf-core-coap-06 Miscellaneous Things

From: Cullen Jennings <[email-masked]>
Date: Wed, 4 May 2011 20:52:57 -0600

I think you need to describe how to mapping large HTTP ETags to CoAP ETag options. You also should address the differences of strong and weak etags. All CoAP ETags are strong. 

Section 6.1 on URL syntax.  The ABNF seems fine but some of the text seem pretty redundant. I would probably drop section 6.3 and 6.4 all together other than discussing the % encoding issue. Fine advice for implementers but I think most people can parse a URL given the ABNF. 

Drop the text "MUST fit within single IP datagram". I will just confuse people and follows from other constraints. 

Move the constants in section 9 up to section 4 to reduce reader confusion. 

I'm not a fan of the human readable error messages fields. They seldom have anything of use for humans and they get used be vendors to stuff in proprietary stuff that should have been in an option. I view them as more harm than good. I expect I am in the "rough" on this so I would prefer if they were not there but if other folks want them in, I don't really care. They are often filled with bandwidth waisting text with zero information content. 

The term "origin server" is never defined. I would either just user server or define what an origin server is. 

The draft uses the term "safe" but it's not clear what changes because of this. Some things are safe or not but no behavior changes based on that so it seems a bit like mention some requests start with G and others don't. You might consider dropping it. 

For the responses codes that are like a HTTP response code. I'd rather see this specification define what they mean in the context of CoAP instead of reusing the HTTP ones. I worry about how an update to HTTP might impact CoAP.

In several places in the draft we have things like (U+0026 AMPERSAND). These are for ascii characters in an ascii document. They should all be removed to be consisted with the style of RFCs. 

We need to pass of figuring out which references are normative and informative. A few looked like they might be off to me but I did not spend the time to check. This can happen a bit later but I did want to flag it. 

I plan to propose something new for the registration process for new entries in in the CoAP Media Type Registry. Right now it looks too hard to get a new entry in this this table. 

Cullen <in my role as an individual contributor>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 May 2011 21:15:05 +0200

On May 5, 2011, at 04:52, Cullen Jennings wrote:

>   I think you need to describe how to mapping large HTTP ETags
>   to CoAP ETag options. You also should address the differences
>   of strong and weak etags. All CoAP ETags are strong.

If we assume that a client always uses the same intermediary to access
a server, it is not necessary to define this (the mapping becomes a
local implementation detail).
Can we assume that?
For forward proxies, that may be fine.
For reverse proxies, it is the job of the reverse proxies to
coordinate their ETags.

(In section 8.1, there should also be a single sentence that we don't
address weak ETags, i.e. the response to the CoAP-side request is not
influenced by the presence of absence of weak ETags on the HTTP side.
In section 8.2, there is no need to discuss weak ETags, as there is no
way to get any.)

>   Section 6.1 on URL syntax.  The ABNF seems fine but some of
>   the text seem pretty redundant. I would probably drop section
>   6.3 and 6.4 all together other than discussing the % encoding
>   issue. Fine advice for implementers but I think most people
>   can parse a URL given the ABNF.

1) Redundancy is fine.  We have enough places where the necessary
other half of the definition is implicitly referred to and can easily
be found in some town hall on Alpha Centauri.

2) What sections 6.3 and 6.4 tell you is how to convert the
information in a URI into CoAP options and back.  We need to fix the
section headings to indicate that.  There is no other place where this
is defined, so there is no redundancy that I can see.

3) An equivalent for the rest of section 6 is in RFC 2616 (potentially
as fixed by httpbis), so I see no way how to get rid of this unless
the same is decided for HTTP.

>   Drop the text "MUST fit within single IP datagram". I will
>   just confuse people and follows from other constraints.

Oh. 1 MUST = 1. We don't need to say that, indeed.

>   Move the constants in section 9 up to section 4 to reduce

I don't care.  At the end of 4.1?

>   I'm not a fan of the human readable error messages
>   fields. They seldom have anything of use for humans and they
>   get used be vendors to stuff in proprietary stuff that should
>   have been in an option. I view them as more harm than good. I
>   expect I am in the "rough" on this so I would prefer if they
>   were not there but if other folks want them in, I don't really
>   care. They are often filled with bandwidth waisting text with
>   zero information content.

There should be some admonition about not wasting bandwidth.

>   The term "origin server" is never defined. I would either just
>   user server or define what an origin server is.

(TODO for terminology section.)

>   The draft uses the term "safe" but it's not clear what changes
>   because of this. Some things are safe or not but no behavior
>   changes based on that so it seems a bit like mention some
>   requests start with G and others don't. You might consider
>   dropping it.

We point to RFC 2616, section 9.1 here.
(This is a place where I'd indeed would like to avoid redundancy, if possible.)

>   For the responses codes that are like a HTTP response
>   code. I'd rather see this specification define what they mean
>   in the context of CoAP instead of reusing the HTTP ones. I
>   worry about how an update to HTTP might impact CoAP.

We probably should do that at some point, indeed.
For now, I did think we might get away with what we have.

>   In several places in the draft we have things like (U+0026
>   AMPERSAND). These are for ascii characters in an ascii
>   document. They should all be removed to be consisted with the
>   style of RFCs.

Actually, they are about characters in URIs.
Yes, we should be consistent with RFC 3986 here.
(This was emulating section 3.1/3.2 of
draft-ietf-hybi-thewebsocketprotocol-07.txt, which probably also needs
to be fixed then.)

>   We need to pass of figuring out which references are normative
>   and informative. A few looked like they might be off to me but
>   I did not spend the time to check. This can happen a bit later
>   but I did want to flag it.

Yes, making sure we don't get a late reclassification of informative
references to normative is important to avoid missrefs.
[I-D.mcgrew-tls-aes-ccm] is the only one I'm worrying about.
(For those who want to help with this: Read section 1.1 of RFC3967.)

In the other direction, we probably want to move to informative:
RFC3023
RFC3602
RFC3676
RFC4627

What about, e.g., RFC4303, RFC4309, RFC4835, RFC5996?

>   I plan to propose something new for the registration process
>   for new entries in in the CoAP Media Type Registry. Right now
>   it looks too hard to get a new entry in this this table.

+1

Gruesse, Carsten (with some help from Klaus)