- From: Phillips, Addison <addison@amazon.com>
- Date: Sat, 16 May 2009 12:40:26 -0700
- To: "public-i18n-core@w3.org" <public-i18n-core@w3.org>
All,
I note this thread on the ietf@ list which may be of interest to our WG.
Addison
Addison Phillips
Globalization Architect -- Lab126
Internationalization is not a feature.
It is an architecture.
-----Original Message-----
From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of ietf-request@ietf.org
Sent: Saturday, May 16, 2009 9:58 AM
To: ietf@ietf.org
Subject: Ietf Digest, Vol 12, Issue 16
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription. To do so, go to
https://www.ietf.org/mailman/listinfo/ietf
Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME. You can set this option
globally for all the list digests you receive at this point.
Send Ietf mailing list submissions to
ietf@ietf.org
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/ietf
or, via email, send a message with subject or body 'help' to
ietf-request@ietf.org
You can reach the person managing the list at
ietf-owner@ietf.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ietf digest..."
Today's Topics:
1. Re: Last Call: draft-crocker-email-arch (Internet Mail
Architecture) to Proposed Standard (John C Klensin)
2. Re: Last Call: draft-crocker-email-arch (Internet Mail
Architecture) to Proposed Standard (Dave CROCKER)
3. Re: Last Call: draft-crocker-email-arch (Internet Mail
Architecture) to Proposed Standard (Dave CROCKER)
4. draft-crocker-email-arch-13 (was: Re: Last Call:
draft-crocker-email-arch (Internet Mail Architecture) to Proposed
Standard) (John C Klensin)
5. Re: Last Call: draft-crocker-email-arch (Internet Mail
Architecture) to Proposed Standard (Alexey Melnikov)
6. Re: draft-crocker-email-arch-13 (was: Re: Last Call:
draft-crocker-email-arch (Internet Mail Architecture) to Proposed
Standard) (ned+ietf@mauve.mrochek.com)
7. Re: Last Call: draft-crocker-email-arch (Internet Mail
Architecture) to Proposed Standard (SM)
8. Re: draft-crocker-email-arch-13 (was: Re: Last Call:
draft-crocker-email-arch (Internet Mail Architecture) to Proposed
Standard) (John C Klensin)
----------------------------------------------------------------------
Message: 1
Date: Fri, 15 May 2009 20:07:52 -0400
From: John C Klensin <john-ietf@jck.com>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail
Architecture) to Proposed Standard
To: Dave Crocker <dcrocker@bbiw.net>
Cc: ietf@ietf.org
Message-ID: <238C061CF55892C01BC12CDF@PST.JCK.COM>
Content-Type: text/plain; charset=us-ascii
Hi.
This is a tiny nit, but, since -13 has not yet been posted...
A few of the references list organizations and not authors as
authors and should probably be fixed. [RFC5335] sort of leapt
out at me. A quick scan also turned up [RFC1652], but I have
not done a comprehensive check for others.
john
------------------------------
Message: 2
Date: Fri, 15 May 2009 19:10:46 -0700
From: Dave CROCKER <dhc2@dcrocker.net>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail
Architecture) to Proposed Standard
To: John C Klensin <john-ietf@jck.com>
Cc: ietf@ietf.org
Message-ID: <4A0E20A6.3030607@dcrocker.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
John C Klensin wrote:
> This is a tiny nit, but, since -13 has not yet been posted...
Thanks.
Since the latest draft has been modified to respond to your recent observations
about internationalization and the role of an architecture document I'm glad to
see that your concerns are reduced to these few typos.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
------------------------------
Message: 3
Date: Fri, 15 May 2009 20:34:55 -0700
From: Dave CROCKER <dhc@dcrocker.net>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail
Architecture) to Proposed Standard
To: IETF Discussion <ietf@ietf.org>
Message-ID: <4A0E345F.4090800@dcrocker.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
FYI,
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-crocker-email-arch-13
and the usual pretty stuff (and diff) are at:
<http://bbiw.net/recent.html#emailarch>
d/
-------- Original Message --------
Subject: New Version Notification for draft-crocker-email-arch-13
Date: Fri, 15 May 2009 19:57:43 -0700 (PDT)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: dcrocker@bbiw.net
A new version of I-D, draft-crocker-email-arch-13.txt has been successfuly
submitted by Dave Crocker and posted to the IETF repository.
Filename: draft-crocker-email-arch
Revision: 13
Title: Internet Mail Architecture
Creation_date: 2009-05-15
WG ID: Independent Submission
Number_of_pages: 54
Abstract:
Over its thirty-five year history, Internet Mail has changed
significantly in scale and complexity, as it has become a global
infrastructure service. These changes have been evolutionary, rather
than revolutionary, reflecting a strong desire to preserve both its
installed base and its usefulness. To collaborate productively on
this large and complex system, all participants must work from a
common view of it and use a common language to describe its
components and the interactions among them. But the many differences
in perspective currently make it difficult to know exactly what
another participant means. To serve as the necessary common frame of
reference, this document describes the enhanced Internet Mail
architecture, reflecting the current service.
The IETF Secretariat.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
------------------------------
Message: 4
Date: Sat, 16 May 2009 00:12:52 -0400
From: John C Klensin <john-ietf@jck.com>
Subject: draft-crocker-email-arch-13 (was: Re: Last Call:
draft-crocker-email-arch (Internet Mail Architecture) to Proposed
Standard)
To: ietf@ietf.org
Message-ID: <F7534DFCDE78A85AA25B6809@PST.JCK.COM>
Content-Type: text/plain; charset=us-ascii
Comment on new text introduced into -13. The text in a new
bullet in 6.3 says
> o MIME's [RFC2045] and [RFC2046] allow for the transport of
> true multimedia material, which has obvious applicability
> to internationalization.
It is not obvious at all. MIME does three things:
(i) It changes the email model from "message plus
attachment" to multiple body parts.
(ii) It provides a way to label textual messages with
character set and language information.
(iii) It provides a way to handle multimedia content.
These three are really independent of each other in the sense
that any one of them without the other two. Absent one of the
originally-anticipated uses of multipart/alternative, which has
never taken off for that use, the first is much more closely
related to the third than the second and is, indeed, almost
irrelevant to the second.
The assertion of obviousness is also unnecessary. The
provisions in MIME for identification of charset and language
are, very specifically, internationalization provisions. The
necessary and sufficient text for the bullet item is simply
something like
o MIME [RFC2045] provides for the identification of
coded character set ("charset") information and, if
desired, language information, which directly support
internationalization.
In addition, the last bullet reads
> o POP and IMAP do not introduce internationalization issues.
If that were true, the EAI work would not require special
specifications and treatment for POP or IMAP.
And, finally on this subject, with those three new bullets, the
"Hence" at the beginning of the last paragraph of that section
no longer makes sense, if it ever did.
john
p.s. It is incorrect to infer from my willingness to try to help
with this document and correct either the type of small errors
identified earlier or the larger ones identified above that I
have dropped my broader and more conceptual objections to the
document or to advancing it onto the standards track.
------------------------------
Message: 5
Date: Sat, 16 May 2009 09:06:05 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail
Architecture) to Proposed Standard
To: John C Klensin <john-ietf@jck.com>
Cc: Dave Crocker <dcrocker@bbiw.net>, ietf@ietf.org
Message-ID: <4A0E73ED.6000400@isode.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
John C Klensin wrote:
>Hi.
>
>This is a tiny nit, but, since -13 has not yet been posted...
>
>A few of the references list organizations and not authors as
>authors and should probably be fixed. [RFC5335] sort of leapt
>out at me. A quick scan also turned up [RFC1652], but I have
>not done a comprehensive check for others.
>
John,
I think RFC Editor can handle these.
------------------------------
Message: 6
Date: Sat, 16 May 2009 07:23:25 -0700 (PDT)
From: ned+ietf@mauve.mrochek.com
Subject: Re: draft-crocker-email-arch-13 (was: Re: Last Call:
draft-crocker-email-arch (Internet Mail Architecture) to Proposed
Standard)
To: John C Klensin <john-ietf@jck.com>
Cc: ietf@ietf.org
Message-ID: <01N90GNNFMEC001ML6@mauve.mrochek.com>
Content-Type: TEXT/PLAIN
> Comment on new text introduced into -13. The text in a new
> bullet in 6.3 says
> > o MIME's [RFC2045] and [RFC2046] allow for the transport of
> > true multimedia material, which has obvious applicability
> > to internationalization.
> It is not obvious at all.
Excuse me? If it isn't obvious that a potential use of multimedia formats is
for internationalization, I don't know what is. The ability to send audio,
video, formats with mulltiple tracks, etc. etc. all have _obvious_ applications
to internationalization.
MIME does three things:
> (i) It changes the email model from "message plus
> attachment" to multiple body parts.
> (ii) It provides a way to label textual messages with
> character set and language information.
> (iii) It provides a way to handle multimedia content.
But the text is specifically only talking about the third at this point, so
what else MIME can do isn't relevant.
> These three are really independent of each other in the sense
> that any one of them without the other two. Absent one of the
> originally-anticipated uses of multipart/alternative, which has
> never taken off for that use, the first is much more closely
> related to the third than the second and is, indeed, almost
> irrelevant to the second.
> The assertion of obviousness is also unnecessary.
Perhaps, but it is obvious, so the assertion has the virtue of accuracy.
> The
> provisions in MIME for identification of charset and language
> are, very specifically, internationalization provisions. The
> necessary and sufficient text for the bullet item is simply
> something like
> o MIME [RFC2045] provides for the identification of
> coded character set ("charset") information and, if
> desired, language information, which directly support
> internationalization.
I agree that mention of this capability of MIME is necessary, but it is not
suffficient. And the text you have here is also technically incorrect - a coded
character set is simply an ordered set of characters, which is NOT sufficient
to specify a charset.
> In addition, the last bullet reads
> > o POP and IMAP do not introduce internationalization issues.
> If that were true, the EAI work would not require special
> specifications and treatment for POP or IMAP.
Er, not exactly. The inability of our current address format to handle
internationalized characters is what creates internationalization issues, not
the POP or IMAP protocols. The EAI work has seen fit to address this by
changing the message format in a way that then requires changes and additions
to all sorts of stuff, including but not limited to POP and IMAP. But POP and
IMAP did not introduce this issue, RFC 822 et al. did.
I therefore believe this statement is true, although perhaps given the lack of
any viable alternativce to the EAI approach it could be considered to be a
vacuous truth. Perhaps rewording this to say something along the lines of:
"POP and IMAP have no difficulties with handling MIME messages, including ones
containing 8bit, and therefore are not a source of of internationalization
issues."
> And, finally on this subject, with those three new bullets, the
> "Hence" at the beginning of the last paragraph of that section
> no longer makes sense, if it ever did.
Agreed - the "hence" is superfluous and should go.
Ned
------------------------------
Message: 7
Date: Sat, 16 May 2009 08:28:50 -0700
From: SM <sm@resistor.net>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail
Architecture) to Proposed Standard
To: dcrocker@bbiw.net
Cc: ietf@ietf.org
Message-ID: <6.2.5.6.2.20090515214346.02ec1dd0@resistor.net>
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi Dave,
At 08:33 15-05-2009, Dave CROCKER wrote:
>The text is not normative and is providing the historical chain of
>development for transfer and content specifications.
If you want to provide the historical chain of development, you'll
have to start with RFC 1341 for MIME. Mail routing is covered in RFC
974. There's also RFC 1123 which updates or annotates portions of
RFC 821 to conform to current usage (at that time). RFC 1123
discouraged all source routing and tried to abolish explicit source
routing for mail delivery.
>The words for Originator are "posting" and "submits". "Send" is a
>different word. It is commonly used in a variety of ways, some
>rather vague. As shown in Figure 2, there really is a logical
>connection between Author and Recipient. Referring to the use of
>that connection as sending to a Recipient.
>
>One of the key points behind a layered architecture like this is
>that these higher-level, logical, end-to-end relationships are
>primary. Author and Recipient perceive themselves as sending to
>each other. They mostly don't perceive all the underlying mechanism.
The paragraph is about the basic test of Gateway design. At the
higher level, they may be a perception that the author is "sending" a
message to the recipient. But we are not operating at that level as
the section is about gateways. The end points are the sender (in
your draft the Originator fits in there) and the recipient. We are
looking at the "connection" between these points where a change in
"addressing", for example, isn't required for the message to get through.
>Hmmmm. Ok. Since the cited specifications do say 'label', I've
>switched the text to say that, although I personally view 'names' as
>more helpful to the reader.
That would have been helpful for a less technically inclined audience.
>Section 4.1.4, Table 1?
Yes.
>The Author, not the Originator, defines the body. MIME structuring
>and labeling is defining the body. It is very much *not* the job of
>the Originator, which has more clerical duties.
We are talking about the "Message Body" here. That should not be
confused with the message content (what the recipient views and not
the raw message. My use of the word "content" may not be technically
correct). MIME structuring is not really part of the content from
the author's perspective if the author and originator are not the
same person. It's up to the originator to see that the message
conforms to Internet Mail standards (Section 2.2.1 of the draft).
>RFC 5321, Section 4.4:
>
> "When the delivery SMTP server makes the "final delivery" of a
> message, it inserts a return-path line at the beginning of the mail
> data."
>
>RFC 5322, Section 3.6.7 -Trace Fields:
>
> "A full discussion of the Internet mail use of trace fields is
> contained in [RFC5321]"
>
>As usual, it is indeed confusing to have redundant definitions in
>two different specifications. Happily, here, one makes clear the
>other is the controlling spec for this item.
Your comment elicited a smile. :-) You mentioned RFC 5322, Section
3.6.7 which references RFC 5321 to explain trace fields. The draft
references RFC 2505 for trace information.
>So email-arch does have an error, here, but it's the opposite of
>what you note. Now fixed.
This brings us back to the document conventions used in the draft
where the first part of a structured field cites the specification
for the field. RFC 5322 has a registration for "Return-Path" in the
Permanent Message Header Field Names registry. The "Received" header
field registration references both RFC 5321 and RFC 5322.
>It needs to be normative.
At the beginning of your reply, you said that the text with a
reference to RFC 2821 and RFC 2822 is not normative. In the draft
STD 10 and STD 11 are Informational references.
Regards,
-sm
------------------------------
Message: 8
Date: Sat, 16 May 2009 12:59:11 -0400
From: John C Klensin <john-ietf@jck.com>
Subject: Re: draft-crocker-email-arch-13 (was: Re: Last Call:
draft-crocker-email-arch (Internet Mail Architecture) to Proposed
Standard)
To: Ned Freed <ned.freed@mrochek.com>
Cc: ietf@ietf.org
Message-ID: <7AB6CC8A319DFC3C9FA3E31B@PST.JCK.COM>
Content-Type: text/plain; charset=us-ascii
--On Saturday, May 16, 2009 07:23 -0700 Ned Freed
<ned.freed@mrochek.com> wrote:
>> Comment on new text introduced into -13. The text in a new
>> bullet in 6.3 says
>
>> > o MIME's [RFC2045] and [RFC2046] allow for the transport of
>> > true multimedia material, which has obvious applicability
>> > to internationalization.
>
>> It is not obvious at all.
>
> Excuse me? If it isn't obvious that a potential use of
> multimedia formats is for internationalization, I don't know
> what is. The ability to send audio, video, formats with
> mulltiple tracks, etc. etc. all have _obvious_ applications to
> internationalization.
Unless one proposes to say that the availability of such media
and that fact that they can be used to transmit non-English
materials is an application to internationalization, I don't
think the link is obvious. And, if one does say that, I
suggest it is almost equivalent to saying that one doesn't
really need non-ASCII character set encoding if image data
(etc.) can be used to transmit images of the relevant other text.
If the document is trying to say what I infer from the above
that you believe it means, I suggest avoiding assertions about
obviousness (which are, I believe, a matter of perspective and
opinion) and say instead something like:
o MIME [RFC2045] and [RFC2046] allows for the transport
of true multimedia material. Such material enables
internationalization because it is not restricted to any
particular language or locale.
I think, given your explanation, that is approximately what was
intended, but it does not make the reader make an inference
about the meaning.
The slight editorial change (from "MIME's ... allow" to "MIME
... allows" is a matter of taste, but I believe the existing
form is confusing because 2045 and 2046 define parts of MIME
rather than being something that MIME owns. A different
formulation would be
o In [RFC2045] and [RFC2046], MIME allows for the
transport of true multimedia material. Such material
enables internationalization because it is not
restricted to any particular language or locale.
Per Alexey's note, I believe that this could reasonably have
been left to the RFC Editor and would not have mentioned it had
I not been suggesting a rewrite to the bullet point for other
reasons.
> MIME does three things:
>
>> (i) It changes the email model from "message plus
>> attachment" to multiple body parts.
>
>> (ii) It provides a way to label textual messages with
>> character set and language information.
>
>> (iii) It provides a way to handle multimedia content.
>
> But the text is specifically only talking about the third at
> this point, so what else MIME can do isn't relevant.
Not the way I read it. That bullet is one among six. As a
collection, they are fairly wide-ranging. One could make the
intention of separate topics and capabilities clear by, e.g.,
changing the bulleted list to an indented one with short titles
that identified the capability groupings.
>...
>> The assertion of obviousness is also unnecessary.
>
> Perhaps, but it is obvious, so the assertion has the virtue of
> accuracy.
Ned, whatever our positions on it from a 10K meter perspective,
I think many (probably most) of us are tired of iterating on
this document. That tiredness may be contributing to
differences of opinion about what will be clear and/or obvious
and/or well-explained (and what will not be) to a first-time
reader who does not already have a deep understanding of
Internet mail. In the case of this relatively new i18n section,
I'm reading it admittedly quickly and through the lens of
spending most of my time lately (both inside and outside the
IETF) on i18n issues. Perhaps if I were less immersed, or more
immersed, the reading you get would be obvious to me. But it
wasn't when I read it yesterday.
When I see "obvious" used in this way, I expect that to be true
for all readers no matter how little exposure they have to the
material. Otherwise, it conjures up all of the old jokes about
stopping a proof part way with "left as an exercise for the
reader", "remaining steps are obvious and trivial", and so on.
And, fwiw, I am willing to suggest alternate text that
accomplishes the same thing without making that assertion and
have done so above. I am not being deliberately obstructive
here-- I want to see the document published and I am trying to
make it better for what I assume is the intended audience.
>> The
>> provisions in MIME for identification of charset and language
>> are, very specifically, internationalization provisions. The
>> necessary and sufficient text for the bullet item is simply
>> something like
>
>> o MIME [RFC2045] provides for the identification of
>> coded character set ("charset") information and, if
>> desired, language information, which directly support
>> internationalization.
>
> I agree that mention of this capability of MIME is necessary,
> but it is not suffficient. And the text you have here is also
> technically incorrect - a coded character set is simply an
> ordered set of characters, which is NOT sufficient to specify
> a charset.
You are, of course, correct about charsets. Having reread the
entire section this morning, that suggested paragraph is also
completely unnecessary -- the topic is covered adequately (and
more accurately) in the first bullet. FWIW, I do think the
section could be made slightly more clear by ordering or
grouping the bullet points so that all of the MIME material
comes together, e.g., that the "multimedia" bullet point should
not be separated from the other MIME material by the EAI one.
But that is probably just a matter of taste.
>> In addition, the last bullet reads
>
>> > o POP and IMAP do not introduce internationalization
>> > issues.
>
>> If that were true, the EAI work would not require special
>> specifications and treatment for POP or IMAP.
>
> Er, not exactly. The inability of our current address format
> to handle internationalized characters is what creates
> internationalization issues, not the POP or IMAP protocols.
> The EAI work has seen fit to address this by changing the
> message format in a way that then requires changes and
> additions to all sorts of stuff, including but not limited to
> POP and IMAP. But POP and IMAP did not introduce this issue,
> RFC 822 et al. did.
That is correct ("obviously" so). As with the above, I think we
are being a little too terse here because, while the sentence is
strictly true as written, I believe that a casual reader might
infer that it implies that no changes to POP or IMAP are needed
for internationalization. Even that inference is true until
one starts to put internationalized characters in addresses.
> I therefore believe this statement is true, although perhaps
> given the lack of any viable alternativce to the EAI approach
> it could be considered to be a vacuous truth. Perhaps
> rewording this to say something along the lines of:
>
> "POP and IMAP have no difficulties with handling MIME
> messages, including ones containing 8bit, and therefore are
> not a source of of internationalization issues."
I typed out a different formulation, but this one works for me.
>...
john
------------------------------
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
End of Ietf Digest, Vol 12, Issue 16
************************************
Received on Saturday, 16 May 2009 19:41:07 UTC