Re: [apps-discuss] Review of draft-ietf-appsawg-rfc3536bis-04

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

Pete,

Having been somewhat involved as a member of the Editorial
Board, one bit of clarification, which might be relevant to the
IESG's considerations, followed by a review of the situation
from my perspective.

--On Friday, July 01, 2011 21:30 -0500 Pete Resnick
<[e-mail]> wrote:

>...
> As I have mentioned to Paul offline, there was some pretty
> stiff pushback on this being BCP. Some of it was of the form,
> "You haven't said it strongly enough" (like Dan's DISCUSS
> comment, where he and others would *prefer* this document to
> be a BCP), and I think with some changes, those folks are
> right on board. There are other ADs (nominally Russ, though
> there are others who support his position) who felt that in no
> event was a glossary the appropriate sort of thing for BCP
> status; it is replacing an existing Informational document,
> and it isn't clear that glossaries are appropriate for BCPs.
> RFC 2026 is not at all precise on this; the only category of
> BCP this could really fall under is if this is meant to
> "document the operation of the IETF itself", which means to me
> that it is a "documentation procedure" (i.e., "we shall use
> these definitions"). 

> The IETF has a perfectly mixed record on
> whether glossaries are BCP Informational, so precedents are
> unclear, the extremes being RFC 2119 (a BCP that defined
> several terms for use in IETF documents as normative protocol
> interoperability statements) and RFC 2828 (an Informational
> document that has a nice list of security terms and their
> definitions, but their use is strictly informational).

The use of 2828 as an example takes "odd" to a new level.  My
recollection was that it was very contentious at the time and
that it was published as Informational (rather than as a BCP or
Standards Track), not because of some philosophical
understanding of the difference among those categories but
because it was clear that consensus on the definitions could not
be achieved for Standards Track (or BCP) publication.  Perhaps
more important, 2828 is identified as "Obsoleted by RFC4949".
Under normal circumstances, the IETF does not look to
obsolescent documents for precedents.  When Rob decided to
expand and replace 2828 a few years later -- my recollection is
that the revision and review process took a long time, probably
several years -- the IESG concluded that it should be handled
through what we now call the Independent Stream, precisely to
avoid a review process in the IETF that would not only be
contentious but that would have the characteristic that no one,
including Rob, would support all of the definitions.  Even as an
Independent Submission, it was clear that 4949 was going to be
contentious enough that it carries, in its "RFC Editor Note",
what I believe is the strongest disclaimer used by the RFC
Editor on an Independent Submission prior to RFC 5741.  I also
note that, while it was published as an Independent Submission,
the IESG decided to classify it as FYI 36.  Probably the FYI
series actually was the right place to publish glossaries, but
the IESG has, in its wisdom, eliminated that series.

Some portion of the reason why 3536 was published as
Informational was a little bit similar to the consensus problem
that occurred with 2828 and then with 4949.   Some of these
definitions are, IMO, detestable (the circularity in the
definition of "glyph" is a good example).   Large fractions of
the linguistic and typographic communities considered the use of
"Latin" to include characters that neither the Romans of the
late Republic nor medieval scribes had ever seen to be a
contemptible exhibition of ignorance.  Some members of the
community (myself included) felt quite strongly that the usage
of those terms had not stabilized enough that the IETF should
attach strong and formal approval to them.  Eight years later,
the use of these terms has stabilized sufficiently --become
routine and common practice in the community-- that Paul and I
were able to collaborate fairly painlessly on the current draft.
There are still terms I don't like, and presumably terms he
doesn't like, but we have no trouble agreeing on the state of
current practice.

Questions about the competence of definitions that originated in
other standards bodies and that are very widely used
notwithstanding, these definitions do have relatively strong
consensus (not just in theory but in use) within the community
in the IETF that is actively working on internationalization
issues. 

Oddly, that is precisely the reason why this revision is
important at this time and that it is important that it be
treated as a normative part of how the IETF does business and
writes documents. Within the portion of the community who
actively work in i18n, there is substantially no disagreement
about terminology and the educated but often intuitive
definitions of terms are harmonious if not identical.  But the
number of development efforts (WG and non-WG) that will find
themselves dealing with i18n issues is on the rise and will
continue to rise.  Efforts to reinvent and rediscover this
terminology, especially by people who are not familiar with the
relevant literature (comments like "just tell me what to do,
don't expect me to read that 5.5 cm thick Unicode thing" remain
very prevalent) are a waste of time at best and, at worst, may
lead to more confusion in the future.  This is the time for the
IETF to take a strong position on the terminology and its
applicability, precisely to avoid ending up in the situations
that motivated the Informational status of 2828 and the ability
to handle 4949 only as an Independent Submission.

> As I suggested, Paul has already written to the IESG some
> explanation of why this document ought to be a BCP. I
> encourage the document editors to continue that discussion.
> Important to the discussion is why you think it is necessary
> and justified that this document to be a BCP instead of an
> Informational RFC.

Obviously, feel free to circulate all or parts of this note if
you think that would be useful.

  best,
     john