New Last Call: 'Tags for Identifying Languages' to BCP

Vernon Schryver vjs at
Tue Dec 14 01:45:51 CET 2004

> From: "Peter Constable" <petercon at>
> To: <ietf at>
> Cc: ietf-languages at

> This is a multi-part message in MIME format.
> --===============1521567419==
> Content-class: urn:content-classes:message
> Content-Type: multipart/alternative;
> 	boundary="----_=_NextPart_001_01C4E16C.40BF0707"
> This is a multi-part message in MIME format.
> ------_=_NextPart_001_01C4E16C.40BF0707
> Content-Type: text/plain;
> 	charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> Bruce Lilly has posted comments on the IETF list in response to the
> last-call announcement for a proposed revision to RFC 3066. His comments
> were generally negative, raising a number of concerns. I and others
> involved in preparation of the revision have discussed Bruce's concerns
> with him, but they were not made available on the IETF list since those
> of us other than Bruce were not subscribed to this list. I wish to
> briefly summarize the outcome of that discussion for the benefit of
> people here.
> =20
> ...

> In conclusion, I think that some of Bruce's concerns were valid, and
> suggestions for changes have been presented to the authors accordingly.
> I believe all of these changes can be considered to be for clarification
> purposes, rather than technical changes. (No changes affecting the set
> of valid tags have been made.)
> ...

> ------_=_NextPart_001_01C4E16C.40BF0707
> Content-Type: text/html;
>       charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> <html>
> <head>
> <meta http-equiv=3DContent-Type content=3D"text/html; =
> charset=3Dus-ascii">
> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
> <style>
> <!--
>  /* Font Definitions */
>  @font-face
>       {font-family:Wingdings;
>       panose-1:5 0 0 0 0 0 0 0 0 0;}
> @font-face
>       {font-family:SimSun;
>       panose-1:2 1 6 0 3 1 1 1 1 1;}
> @font-face

On the contrary, what the authors of a standard intend is not normative.
As much as possible, every standard must say what it means, because
what a standard says *is* its technical content.  For example, I'm
unhappy about an apparent sentiment that would put ABNF on a lower
footing that the English text.  I think I'm like most implementors and
perhaps unlike non-engineers in reversing that precedence.  Whenever
I read an RFC, I rely first and foremost on the ABNF.  I use the English
only for hints, and follow the ABNF instead of the English whenever
there is a conflict.

There are a couple other issues that ought to be addressed.

I think Bruce Lilly started by charging that a potentially disruptive
document had reached last-call without any review by those concerned
with related, affected IETF standards.  That sounds like a process
problem that needs at least 1% as many words as have been spent in
this mailing list in lawyerly talk such as whether "accounts" is more
appropriate than "account."

The other issue is that some of us consider the completely unnecessary
and gratuitous use of duplicate-copy/quoted-printable/HTML email
somewhere among aggressive, offensive, and a security attack.  In
purely text contexts like this mailing list QP/HTML never contributes
to an impression of technical accuracy and relevance of whatever
message it enciphers.  Then there is the use of Microsoft's XML
flavor of HTML mail ...

Vernon Schryver    vjs at

More information about the Ietf-languages mailing list