Subject: [core] draft-ietf-core-coap-06 Unicode Normalization

From: Cullen Jennings <[email-masked]>
Date: Wed, 4 May 2011 20:49:30 -0600

I don't think this draft needs to say anything about unicode or UTF-8. The format of the relevant parts is defined by reference to the ABNF used in HTTP. What implementations do is treat this all as binary data and I think the is the exactly right thing to do. The spec should just say it is binary data. All references to UTF-8 and NFC can be removed as well as the string time can just be changed to the opaque type. I think doing this change will up the odds of interoperability. The HTTP specs will already take care of the parts of of HTTP that are UTF-8 and the way we reduce the ABNF ensure an good mapping between CoAP and HTTP. The way I would interpret the draft as the current text stands would cause me to use normalized form C where other people would not resulting in really hard to debug interoperability problems as the management tools would probably print things in way in the debugging information where two things that were actually different looked the same when you looked at them in the management tool. It all seems like a huge hassle with no gain. I have asked several people what we get by specifying UTF-* over binary data and everyone says, oh, but we are really just processing it as binary data. The real problem I see with saying NFC, or even UTF-8, is what happens when you get data that is not. Do you return an error or do the canonicalization. Either answer results in needing to do something that I really don't want to do on a constrained system so I prefer the answer of of do neither and just ignore it. But at hat point we are doing binary data not NFC UTF-8. 

Cullen <in my role as an individual contributor>