Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-00.txt

[John C Klensin <[e-mail]>]

--On Monday, May 09, 2011 08:23 -0700 Paul Hoffman
<[e-mail]> wrote:

>...
>> Proposal for inclusion of definition in Section 8.  I think
>> we could also define "noncharacter" here (and appropriate
>> entry in the Index).  My proposed definition:
>> 
>>>      noncharacter
>>>        
>>>         A noncharacter is a code point that is permanently
>>>         reserved in some particular coded character set and
>>>         is generally  forbidden to be used in open data
>>>         interchange. <UNICODE>
> 
> "noncharacter" is not a term commonly used in
> internationalization, I believe.

The term is also fairly Unicode-specific.  While I agree with
Paul's answer, two additional observations:

(1) This document is about internationalization terminology, not
about characters, character sets, and terminology about them.
It is impossible to have a discussion about i18n (at least in
written text) without dealing with a lot of character set
issues, but that does not imply that all character set issues
and terminology should be included.

(2) With a possible exception when some definitional universe
falls cleanly into "A and not-A", one is always better off
defining things as what they are (or what the category
includes), rather than what they aren't.  While I understand
what the Unicode folks were trying to do and why, and am
relieved that no one asked me about a better term,
"noncharacter" isn't a strict opposite of "character".  Indeed,
if one adopts some common definitions of the "character"
category, "noncharacter" becomes a subset with a particular set
of properties.  In that context, the definition above isn't
really a definition but a description because "generally
forbidden" is insufficient to define what is in the category and
what isn't.  That is not a problem for Unicode because also all
of their terminology is descriptive: category-assignment is not
a consequence of definitions but of tables. If we were to define
it, we would have to include disclaimers about using the term.
I don't see that as worthwhile unless the term were used
prominently in i18n contexts in the IETF and, as Paul suggests,
it isn't.

>> To finish, why the intended status for this draft is BCP?
>> Longstanding IETF practice is to publish glossaries as
>> Informational docs (previously, FYIs); examples are
>> http://tools.ietf.org/html/rfc1208,
>> http://tools.ietf.org/html/rfc1983,
>> http://tools.ietf.org/html/rfc4949 and the predecessor of
>> this draft itself - http://tools.ietf.org/html/rfc3536.  I
>> think Informational would suit better here.
 
> As you are well aware, there is differing opinion on this.

Actually, "longstanding IETF practice" is to publish materials
that are normatively required for standards-track documents as
BCPs or on the standards-track, both because that makes sense
and because it avoids "normative reference" problems (I note
that draft-housley-two-maturity-levels makes no provision for
downward references to Informational documents, leaving RFC 3967
unchanged as the only way to deal with such references).  The
most-widely-cited example of this is BCP 2119.  

One way to look at the distinction is that some documents (RFCs
1208, 1392, and 4949 included) are glossaries that are
essentially descriptive of common contemporary practice.  So,
arguably, was 3536 itself.  Other documents are efforts to
normatively establish terminology and conventions for use
(especially) in standards-track documents.  While a good
document of that sort is always going to be written to avoid
confusion with popular terminology that is then in use, and to
identify that confusion when necessary), it is intended to
establish a usage model, not just describe one.  This document
joins 2119, 5137, and the "terminology" sections of many, many,
standards-track documents in that category. 

> We'll let the higher-ups decide.

Yes.   But, IMO, this makes sense to publish as Informational
iff there is a simultaneous RFC 3967 action to make it ok to
reference it normatively from standards-track documents.  That
would seem to me to be a poor use of resources, especially given
the precedents discussed above, but others may disagree.


regards,
     john