ietf-smtp
[Top] [All Lists]

Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

2009-02-27 20:45:24



--On Friday, February 27, 2009 16:50 -0800 Dave CROCKER
<dhc(_at_)dcrocker(_dot_)net> wrote:

John,

With respect to character set, internationalization, and the
like, I cannot tell what text changes you propose for the
document.  The current text was developed through community
discussion.

 What specific changes are you proposing?

s/old/new/ form, or a multiline equivalent, would be most
helpful.

I suggest that the bulk of any changes really does need to
refer to community consensus documents, rather than trying to
summarize the topic.

Actually, Dave, I can remember no community discussion of the
Internationalization section of this document.   And while I
tend to agree with you about reference to community consensus
documents, that section does not reference one.  Instead, it
references (given how little text is in the Internationalization
section, "incorporates by reference" might be more accurate) a
somewhat-outdated private consortium document that has never had
anything resembling formal IETF review.

While this document has been kicking around the community for
quite a while and gotten comments and input from far more people
than are listed in the Acknowledgements, it is an individual
submission for the standards track, not a WG product subsequent
to a IETF-approved charter.   If the IESG is consistent with the
criteria it has applied to a large number of other individual
submission documents in the last year or so, the question is "is
it ready" rather than "can the author insist that IETF
participants put other work aside to do a sufficiently close
review of a 49 page document to suggest alternate text that is
consistent with other text in the document".  

I've demonstrated (and will demonstrate further below) that at
least this one section is not ready and have suggested what is
needed to fix it -- describe the current internationalization
status in sufficient detail to either eliminate the need to
reference "[MAIL-I18N]" or to reduce it to a clearly
informative, "additional reading" reference.   

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".
Personally, I would object less to your saying nothing (or to
saying the above, which is equivalent) than to your hand waving
and then pointing off to a decade old non-consensus document
that is outdated in several areas.   But, while it is a pity to
hold the architecture document up because of [MAIL-I18N], if
that document represents what you have to say architecturally
about i18n issues, then it is normative and your document isn't
ready to go until it is... or until the reference to it can be
eliminated.  

For example, [MAIL-I18N] points to RFC 2279, which has been
obsolete for more than five years due to a definitional change,
for an authoritative definition of UTF-8.  It also points to and
recommends Unicode TR 7 for inline language tagging.  That
document was withdrawn years ago, the link given in [MAIL-I18N]
no longer works, and the material that supercedes it (Section
16.9 of TUS 5.0 for an accessible reference) has, as its second
sentence, "The use of these characters is strongly discouraged".
That rather clear statement is followed by a discussion of
alternatives (e.g., XML or HTML) and conditions under which the
tags might be appropriate, none of which obviously apply to
Internet mail.

Several of its other references, to both IETF and non-IETF
documents, are obsolete as well.

    john