ietf
[Top] [All Lists]

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

2017-04-25 15:10:15
On Apr 25, 2017, at 11:59 AM, Carsten Bormann <cabo(_at_)tzi(_dot_)org> wrote:

On Apr 25, 2017, at 18:46, Julian Reschke 
<julian(_dot_)reschke(_at_)gmx(_dot_)de> 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.

Well, that's broken.

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].)

That isn't a "limitation".  It's a bug to decode pct-encoded octets in
a URI before decomposing the reference into its parts.  ASCII is already
in UTF-8.  Decoding a pct-encoding doesn't make it "more UTF-8"; it just
means the string is no longer a URI reference.  That's broken.  So utterly
broken that it obviously wasn't reviewed by the right people.

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.

*sigh*

....Roy