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

From: Andrew Sullivan <[email-masked]>
Date: Fri, 1 Jul 2011 12:24:17 -0400

Dear colleagues,

As usual, a day late and a dollar short, but I have reviewed
draft-ietf-appsawg-rfc3536bis-04.  I support its publication.  I have
some items that might conceivably be addressed, but I don't think any
of them is a show-stopper.  I sent nits I observed directly to the WG
draft editors.

First, in section 1.1, we have this:

   The definitions here should be used by IETF standards that want to
   use them.  IETF standards that explicitly want to create different
   definitions for the terms defined here can do so, but the terms
   here should be considered the default for IETF standards after the
   time of publication of this document.  

Obviously, the draft can't constrain what other documents might do.
But it would be nice to encourage other documents, if they're going to
come up with different definitions, to use different words.  If
someone decided to re-define SHOULD at the beginning of their
standards document, we would quite justifiably complain, & I think the
same goes here.  I suggest the following additional sentence: 

    IETF standards that want different definitions are encouraged, for
    clarity's sake, to find terms different to the ones defined here.

Second, why isn't "LDH label" in section 7 instead of section 6,
especially since LDH is also mentioned at the beginning of section 7?

The last sentence of the first paragraph of section 8 says, "It is
likely that additional terms will be added as this document matures."
Presumably, if the draft is published that sentence should be removed.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 Jul 2011 12:28:58 -0700

Answering one of the questions (the others seemed fine).

> especially since LDH is also mentioned at the beginning of section 7?

Because the definition of LDH label in section 6 is the pre-IDNA definition, not tied to IDNA. It seemed appropriate there because other protocols also think in terms of "what characters are seen in host names".

--Paul Hoffman

---

From: John C Klensin <[email-masked]>
Date: Fri, 01 Jul 2011 16:00:07 -0400

--On Friday, July 01, 2011 12:24 -0400 Andrew Sullivan
<[email-masked]> wrote:

> draft-ietf-appsawg-rfc3536bis-04.  I support its publication.
> I have some items that might conceivably be addressed, but I
> don't think any of them is a show-stopper.  I sent nits I
> observed directly to the WG draft editors.

Thanks for the nits.  A few comments on your comments below,
with the understanding that we are waiting for detailed feedback
from the IESG at this stage (and that Paul has the pen on this
cycle).

>    The definitions here should be used by IETF standards that
> want to    use them.  IETF standards that explicitly want to
> create different    definitions for the terms defined here can
> do so, but the terms    here should be considered the default
> for IETF standards after the    time of publication of this
> document.  
> 
> Obviously, the draft can't constrain what other documents
> might do. But it would be nice to encourage other documents,
> if they're going to come up with different definitions, to use
> different words.  If someone decided to re-define SHOULD at
> the beginning of their standards document, we would quite
> justifiably complain, & I think the same goes here.  I suggest
> the following additional sentence: 
 
>     IETF standards that want different definitions are
> encouraged, for     clarity's sake, to find terms different to
> the ones defined here.

In drafts of this document up this stage, we have tried to
preserve the informative/ descriptive/ persuasive tone of RFC
3536 while pushing in the direction I think you are encouraging.
Some IESG members have pointed out that the document doesn't
sound normative enough to be a BCP.  In retrospect, trying to
circle around the issue (for which I am more to blame than Paul)
was probably unwise.  Depending on what the IESG has to say
(i.e., what Pete tells us), we are contemplating rewriting that
explanation into RFC 2119 language and simply saying that these
definitions SHOULD be used in IETF documents and that, if people
choose to not use them, they MUST define the terms they are
using exactly and preferably use terminology that does not
overlap.

Your thoughts on whether that is a good strategy would be
welcome.

> Second, why isn't "LDH label" in section 7 instead of section
> 6, especially since LDH is also mentioned at the beginning of
> section 7?

Sort of a judgment call.   Remember that "LDH label" and its
variants have been used pretty extensively in non-IDN DNS
terminology to describe labels that meet the "preferred name
syntax" criteria of RFC 1034, i.e., to distinguish those
preferred-syntax strings from binary labels and ASCII labels
that contain spaces, symbols, or C0 characters.   The term was
invented when it became clear that "hostname" was sometimes used
as a synonym for the preferred name syntax, sometimes to refer
to the first label component of an FQDN, and sometimes to refer
to an FQDN that was associated with certain RR types.   "LDH
label" is at least clear about which of those cases is intended.

Speaking personally (I haven't consulted Paul), my preference
for this term and a few others would be to take the definition
out of this document entirely, instead referring to a document
that provide normative definitions for terminology used with the
DNS.  If such a document existed, those terms in this document
could be reduced to a list and a reference, much like the list
in Section 7.1.   I can only offer my condolences on the state
of that document, but holding 3536bis (or anything else) up
waiting for it seems unwise.

> The last sentence of the first paragraph of section 8 says,
> "It is likely that additional terms will be added as this
> document matures." Presumably, if the draft is published that
> sentence should be removed.

Although it could be read as anticipating further revisions to
this document over the long term, I agree that it is confusing
at best.

best,
    john

---

From: Pete Resnick <[email-masked]>
Date: Fri, 1 Jul 2011 21:30:40 -0500

On 7/1/11 3:00 PM, John C Klensin wrote:

>> justifiably complain,&  I think the same goes here.  I suggest

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).

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.

This document will at the very least be published as Informational. But 
I have put it back on the next IESG telechat to continue the 
conversation. On 14 July, we're going to make a call one way or the 
other. Please complete your discussion before then.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: SM <[email-masked]>
Date: Sat, 02 Jul 2011 01:10:24 -0700

At 19:30 01-07-2011, Pete Resnick wrote:
>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).

Section 1.1 mentions the following as one of the purposes of the document:

   "The definitions here should be used by IETF standards that want to use
    them. IETF standards that explicitly want to create different
    definitions for the terms defined here can do so, but the terms here
    should be considered the default for IETF standards after the time of
    publication of this document.  Some of the definitions in this
    document come from many earlier IETF documents and books."

Would rewriting the above as:

   "The definitions here SHOULD be used by IETF standards that want to use
    them. IETF standards that explicitly want to create different
    definitions for the terms defined here can do so, but the terms here
    MUST be considered the default for IETF standards after the time of
    publication of this document.  Some of the definitions in this
    document come from many earlier IETF documents and books."

make this BCP material?

The purpose of BCP 161 is to provide a definition of a term for use 
in all future IETF documents that refer to the term.  The difference 
between that BCP and this draft is that the title does not say 
"Guidelines".  BCP are meant to express community consensus.  In 
other words, it can be view as "these are the terms that have been 
used in discussions about internationalization; and the IETF agrees 
that these terms are the default as from the date of publication of this draft.

If a test was required to determine whether the draft should qualify 
as BCP, I suggest the following:

   Is there disagreement in the IETF community on the definitions used?

   Is there a sense of rough agreement in the internationalization
   community on the definitions used?

The last question is to avoid a disconnect between the IETF and reality.

The DISCUSS raised by Dan Romascanu could be addressed by having 
Section 1.1 cover what has changed since RFC 3536.

BTW, "IETF members" (Section 6) should be changed to "IETF participants".

As it (the draft) stands, I don't see a strong case for a fight about 
the intended status.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Sat, 02 Jul 2011 04:33:50 -0400

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
<[email-masked]> 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

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 4 Jul 2011 02:08:58 -0400

> Your thoughts on whether that is a good strategy would be

Either that, or (failing it) adding something the sentence I suggested
(which is just intended to say, "Hey, play nice!"), would be a good
idea, in my opinion.

> DNS.  If such a document existed

I'm sure we'd all rejoice were such a document to be written and to
achieve consensus.  But I understand the reasoning.

A

-- 
Andrew Sullivan
[email-masked]