Date: 2005-07-08 01:08
From: Frank Ellermann <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
Bruce Lilly wrote:
BCP 18 (RFC 2277, Frank) recommends an internationalization
considerations section
Oh, that beast, a MUST UTF-8, not less. Didn't make it into
RfC 3912, can I declare it "broken by design" and return to
RfC 954, please ?
Not now. Within two months of the public announcement of the decision,
(BCP 9, a.k.a. RFC 2029, section 6.5.4) you could have initiated an
appeal or a discussion with the IETF Chair if you felt that there was
some sort of process failure and if you thought such an approach would
be productive. At this late date, you can of course still send
comments to the author.
While we're at it, did you see draft-hoffman-utf8-rfcs-00.txt ?
I saw it, downloaded it, glanced through it. Not surprising to me,
since some time ago (IIRC during review of the I-D Checklist here)
I briefly mentioned the ASCII-only rule and explicitly deferred
discussion of that to those who are most directly affected, e.g.
authors whose names contain non-ASCII characters (I didn't wish
to open that particular can of worms at that particular time).
If the IETF feels that internationalization is an important
issue, a similar guideline prompting authors/editors to
include, and reviewers to review such a section might be
worth adding.
Maybe. OTOH it wouldn't be polite to write "SMTP error texts
are i-default US-ASCII, stupid, so that's what you put in an
SPF exp= explanation, for more I18N you could use a http URL".
It also wouldn't be of much interest, as SMTP requires protocol
actions based solely on the reply code (first digit), and the text
must not be used as the basis for action (with a notable
pseudo-exception, where the "text" is a public name rather than
"text" in the BCP 18 (RFC 2277) sense). There might, however, be
cause to examine the SMTP protocol in terms of providing a BCP 18
conforming mechanism for tagging the text charset and language, and
for provision for charsets other than US-ASCII (considering the
application, adoption of the BCP 18 conforming mechanism specified
in RFC 2047 as amended by RFC 2231 and errata might be a good
choice).
The IPR boilerplate makes me mad, but unfortunately the authors
of xml2rfc didn't adopt my ipr="full<meep>" or ipr="fulleula"
proposals. Insert four-letter word for <meep>. At most three
lines pointing to a "creative commons BY SA license" should be
good enough for most I-Ds.
Ah, but you misunderstand the purpose of legal boilerplate -- it
isn't supposed to make sense, it's supposed to confound common
sense (see Jonathan Swift's "Gulliver's Travels"), and to provide
full employment for lawyers (which may explain why it always seems
to be in need of revision) .-, (<- that's half a smiley :-)). If
you look at the IPR boilerplate in those terms, it's fulfilling its
purposes ("HE/SHE" applied to all-male or all-female authors,
reference to "this standard" for mere drafts and all RFCS ("Not All
RFCs are Standards" hasn't been rescinded AFAIK), etc.).
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf