> On Apr 25, 2017, at 11:59 AM, Carsten Bormann <cabo@xxxxxxx> wrote: > > On Apr 25, 2017, at 18:46, Julian Reschke <julian.reschke@xxxxxx> 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