A couple more comments (this time with an author hat on): On Mar 27, 2013, at 14:33, "Romascanu, Dan (Dan)" <droma...@avaya.com> wrote:
> 1. I could not find at any place in this document a dull mention of the > transport mapping on UDP and of the fact that a node supporting CoAP MUST > support UDP. On the contrary, in several places a language used mentions a > 'datagram-oriented transport such as UDP'. This is somehow intriguing, I am > missing a more specific definition of the mandatory transport. 3. Message Format CoAP is based on the exchange of short messages which, by default, are transported over UDP (i.e. each CoAP message occupies the data section of one UDP datagram). CoAP may also be used over Datagram Transport Layer Security (DTLS) (see Section 9.1). It could also be used over other transports such as SMS, TCP or SCTP, the specification of which is out of this document's scope. In the end, what transport is used is implied by the URI, so I wouldn't even go so far as considering UDP to be a "mandatory" transport (although in practice completely getting rid of the default UDP mapping may require DTLS to gain multicast capability). > 2. The terms of 'constrained node' and 'constrained network' are widely used > but never defined in this document (but by example in the introduction). I > would suggest to include a definition in section 1.2 (Terminology) or a > reference if proper definitions can be found some place else. A draft is nearing completion in LWIG that is defining these and other terms relevant to this field. "Terminology for Constrained Node Networks", Carsten Bormann, Mehmet Ersue, 25-Feb-13, <draft-ietf-lwig-terminology-01.txt> We should reference this as an informative reference. > 3. It would be good to define in section 1.2 (Terminology) or provide a > reference for the term of 'resource' as this specification used it (again, > defined only by example when talking about 'resource discovery') Indeed. For this central term, we could simply make more explicit the reference to RFC 2616. (Section 1.2 says: This specification requires readers to be familiar with all the terms and concepts that are discussed in [RFC2616]. [...] We could expand this into: This specification requires readers to be familiar with all the terms and concepts that are discussed in [RFC2616], including "resource", "representation", "cache", and "fresh". [...] ) > 4. Section 3 - is there any special reason for the Version (Ver) field to > start with the value 1 for this version? For a two-bit field this seems a > waste we would rather avoid. Nothing prevents calling this version of CoAP > 'version 1' and code it 00 on the wire. We were trying to avoid on-the-wire values that could be confused with the UDP payloads of STUN or DTLS. This is generally a good strategy for diagnostic and debugging purposes. (If need be, we can always wrap around the version number and represent 4 as 0b00. We could even allocate more bits for the version number in version 2 upwards. However, the protocol has a number of well-defined extension points apart from the version number, so I would consider it unlikely that we will arrive at this need.) Grüße, Carsten _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
