[rfc-i] How lack of Unicode support in IDs is detrimental to design

[Dave Crocker]

> But Phill was talking about a case where he is planning to put UTF-8
> _in the protocol_, and make that UTF-8 significant in the protocol;
> and he was quite correctly pointing out that providing zero examples
> to show how this could happen is an excellent way to ensure that some
> underpaid contract programmer with half an attention span will
> implement the protocol in the future without handling the UTF-8
> encoded protocol fields, and then there'll be an interoperability
> problem.  I agree with him.


We've been using the current document format (with ASCII-only 
limitations) to specify binary-based protocols for more than 40 years. 
They've included examples.  Somehow, folks have managed to write them 
and other folk have managed to understand them well enough to achieve 
interoperability.

I am not understanding what it is that makes UTF-8 more special than IP 
or TCP binary headers, or ASN.1 encodings or...

It's not that UTF-8 support in RFCs is a bad idea, it's that claiming 
that its absence is a serious problem is.

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net