Dave,
I don't think much can be accomplished by an extended debate
about our respective points. I've injected my comments into
the Last Call bin, you have injected yours. As both of us have
pointed out on many other occasions, this is not about seeing
how many endorsers one can get.
You will probably like some of my more general comments on the
document even less. Please at least acknowledge that I am
entitled to have those opinions.
--On Friday, February 27, 2009 18:52 -0800 Dave CROCKER
<dhc2(_at_)dcrocker(_dot_)net> wrote:
...
Personally, I suspect you'll have an easier time of it if you
suggest specific text. (As for making the text "consistent
with other text in the document" I'd be glad to perform that
task, given any rough approximation that folks like.)
That is a reasonable proposed compromise. I am still concerned
that elements of this may be controversial enough that a WG
process is really required. Most of those issues have been
aired before, especially vis-a-vis terminology that carries
highly loaded semantics with it, semantics are are particularly
sensitive given various efforts to establish mechanisms for
email sender authentication or authorization. I will explain
that further in another note, but they are issues that have been
raised before.
An alternative, if you could get the IESG to agree to it,
would be to say, somehow, "the Internet's email system is
mostly ASCII although various changes have been made and are
being made to accommodate non-ASCII strings in appropriate
contexts; internationalization is not further discussed in
this document".
Well that is, indeed, specific text.
Are you suggesting it replace the existing Section 6.3 text?
What I'm suggesting is that you need to do one of two things:
(i) Get community consensus and IESG agreement to explicitly
blow off the internationalization issues. I can personally live
with that as long as it is done explicitly, either with a "just
not discussed here" statement like the one above or with a
forward pointer to a document that may never be written. I
note that either one would violate a BCP and some explicit
policy statements but that procedural issue is a separate
problem.
(ii) Write something real for Section 6.3 and put it there.
That might start with a trimming and reworking of the IMC
document (see Paul's "should not be referenced in a modern
architecture document" comment -- one of the few I18N-related
areas in which the two of us are in agreement). Much of the
material there is good. Some can just be left out. The
references need to be updated and some of the text needs
reconsideration in the light of things that have happened in the
last decade. I would volunteer to work with you and/or Paul on
the rewrite, but I really have to devote all of my
internationalization cycles right now to the IDNABIS WG.
However, if a revised version of that text were folded into the
architecture document and included in a Last Call, that would
obviously satisfy my concern about a normative reference to a
non-consensus document.
Are you seeking support for that replacement from others on
the list?
No. I am asserting my belief that, without one of the choices
above, the document is incomplete and not ready for prime time.
I am completely agnostic about which choice is made although I
believe that the requirements for a meaningful
internationalization session are more comfortably waived for an
informational document than for a standards track one.
For example, [MAIL-I18N] points to RFC 2279, which has been
obsolete for more than five years due to a definitional
change,
What is the superior reference you suggest be used?
A quick glance at the rfc-index, or faking an I-D format for
[MAIL-I18N] and pushing it through the reference checker, will
quickly point you to RFC 3629, a full Internet Standard.
Depending on what else is being said, an additional reference to
RFC 5198 might also be relevant. But note that these are
references out of [MAIL-I18N] and not the architecture document
itself. They are irrelevant if you adopt the first option above
and would probably fall out fairly automatically in any
extraction of text from, and revision of [MAIL-I18N] for
incorporation into the architecture document as suggested in
(ii).
john