Re: [art] Artart last call review of draft-ietf-core-links-json-07

[Carsten Bormann <[e-mail]>]

On Apr 25, 2017, at 18:46, Julian Reschke <[e-mail]> wrote:
> 
> Do you have a specific problem in mind?

This work was done half a decade ago (May 18, 2012, that is), so I don’t remember all the details.
RFC 6690 says:

   In
   order to convert an HTTP Link Header field to this link format, first
   the "Link:" HTTP header is removed, any linear whitespace (LWS) is
   removed, the header value is converted to UTF-8, and any percent-
   encodings are decoded.

So we get rid of all that fun before it becomes RFC 6690 (and CoAP of course is all UTF-8 in any case).

So far, we have run into one real case where that approach is a limitation, and that is in URIs:

The link

coap://example.com?stupid%3Dkey=4711

is not distinguishable from

coap://example.com?stupid=key=4711

(The typical reaction of an implementer is “then don’t do that!” [1,2].)

We know that because the CoAP protocol itself also completely runs in the UTF-8 domain (there is no percent encoding on the wire); I’m not sure that simplification actually hurt in RFC 6690 use cases yet.

(Note that it is rather likely to see user-visible strings in DNS-SD instance names, which turn into “ins” link attributes, so this is not only a URI/IRI/WVUS [3] issue.)

We don’t have a lot of experience with lingering legacy charsets in HTTP headers in the constrained space, so I’m sure there are other side effects.

Grüße, Carsten

[1]: http://www.condenaststore.com/-sp/Then-don-t-do-that-New-Yorker-Cartoon-Prints_i14788077_.htm
[2]: http://www.catb.org/~esr/jargon/html/D/Don-t-do-that-then-.html
[3]: https://url.spec.whatwg.org/#valid-url-string (WHATWG Valid URL String, or WVUS for short)