[core] Comments on draft-shelby-core-coap-req-00.txt

[Alexey Melnikov <[e-mail]>]

   REQ13:  Internet media type and transfer encoding type support.
           [I-D.sturek-6lowapp-smartenergy], [I-D.gold-6lowapp-sensei]

Why is support for multiple Content-Transfer-Encodings is needed? Any 
C-T-E other than 8bit increases size of messages
and cost of implementation, which are 2 other requirements mentioned in 
the document.

2.2.  Basic Messages

   It is assumed that basic Request and Response messages will be
   required by the CoAP protocol.  This also provides a natural mapping
   to HTTP (See Section 2.10) and the response may be useful as an
   acknowledgement in UDP reliability (See Section 2.8.1).  It can be
   considered that CoAP methods are different kinds of Request messages,
   therefore a separate Request message is not needed.

I don't understand the last sentence.

2.4.  Content-type encoding

   In order to support hetergenous uses, it is important that CoAP is
   transparent to the use of different application payloads.  In order
   for the application process receiving a packet to properly parse a
   payload, its content-type and encoding should be explicitly known
   from the header (as e.g. with HTTP).  The use of typical binary
   encodings for XML is discussed in [I-D.shelby-6lowapp-encoding],
   which includes recommendations for header indication.  The draft
   recommends the indication of at least 10 Internet media types (MIME)
   [RFC2046] and 2 content transfer encodings.

As above, I am not convinced that you need to support multiple C-T-E in 
COAP.

   It is obvious that string names of Internet media types [RFC2046] are
   not appropriate for use in the CoAP header.

Well, and URIs are Ok why?

   But then how to make
   this small yet extensible?  One possible solution is to simply assign
   codes to a small subset of common MIME and content transfer encoding
   types and have IANA maintain that.  A field of 16-bits should be
   sufficient for encoding both media and content transfer encoding
   types.  For extending some types, magic numbers can also be used from
   the beginning of the payload (as defined in associated Internet media
   type RFCs).  This could be indicated by a header value something like
   "See magic numbers".

Hmm. The list of MIME types is small and can be easily encoded. It 
hardly ever changes.
I suppose subtypes can be enumerated.
If this is going to be an extension to the existing MIME media type 
registry, I suggest discussing this with Ned Freed and John Klensin.

2.5.  URLs

   The Universal Resource Locator (URL) [RFC3986] is an important
   feature of the REST architecture, the relative part of the URL
   indicates which resource on the server is being manipulated.  It is
   surely useful for CoAP to support string URLs, which requires a
   variable length-value field.  Although URLs can be designed for
   compactness, this still often results in 10s of bytes of overhead.
   The encoding of the URL string also needs to be considered, as this
   is becoming increasingly complex.  It is recommended that only US-
   ASCII is supported in URL strings for CoAP as defined in [RFC3986],

Basically you are saying that you want URIs, but not IRIs.
And RFC 3986 only describes URIs.

   or even a stricter subset as URL parsing

I recommend against putting further restrictions to URIs. URI/IRI/URN 
are already complex, this will make the UR* world even more complicated.
I also don't think that this WG is the right place to define 
restrictions on URIs.

   is complex and may result in security problems on constrained devices.

This is true. This might mean that URIs is not what you want. But I 
would be afraid to recommend that you design something new. This task 
itself might take years.

Regards,
Alexey