[rfc-i] feedback on draft-hoffman-rfcformat-canon-others-00, was: RFC Format - final requirements and next steps

Joe Touch touch at isi.edu
Thu May 17 13:37:28 PDT 2012



On 5/17/2012 1:25 PM, Julian Reschke wrote:
> On 2012-05-17 22:17, Joe Touch wrote:
>>
>>
>> On 5/17/2012 1:11 PM, Julian Reschke wrote:
>>> On 2012-05-17 22:04, Joe Touch wrote:
>>>>
>>>>
>>>> On 5/17/2012 12:28 PM, Julian Reschke wrote:
>>>> ...
>>>>>> We probably also need to define what we expect happens to invalid
>>>>>> sequences and "Private Use" sequences, or to prohibit their use as
>>>>>> well.
>>>>>
>>>>> No, we don't need to discuss invalid documents. Just don't produce
>>>>> them.
>>>>> They are invalid.
>>>>
>>>> Private Use codes aren't invalid.
>>>
>>> Come on.
>>>
>>> They are "private use". Why would we want them inside a spec?
>>
>> 1) we could say that they're prohibited
>>
>> 2) we could define a use for them in RFCs and require their support
>>
>> My point with these and the control codes was that the doc had a small
>> oversight - it should say "printable UTF8 excluding Private Use, and a
>> fixed subset of control chars", not merely UTF8.
>
> You are again confusing character encoding scheme with character
> repertoire.

As does the doc to which I refer:

    o  The text encoding for the document is UTF-8.  The RFC Editor can
       decide where it is and is not appropriate to use non-ASCII
       characters in the RFC.  For example, the RFC Editor might make
       rules about using non-ASCII characters in people's names,
       reference titles, examples in text, and so on.

The first sentence is about encoding. The rest is about limiting the 
subset of the encoding that is permitted, but it is insufficient.

And it's not the character repertoire that concerns me; it is the 
control repertoire.

Joe




More information about the rfc-interest mailing list