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
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
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
--On Saturday, May 16, 2009 07:23 -0700 Ned Freed
ned.fr...@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
On 5/16/09 5:28 PM, SM wrote:
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
At 05:27 13-04-2009, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Internet Mail Architecture '
draft-crocker-email-arch-12.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
(just in time for shipping the final version for IESG consideration after Last
Call...)
SM wrote:
In the Introduction section:
The underlying technical standards for Internet Mail comprise a rich
array of functional capabilities. The specifications form the core:
* Simple Mail
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
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
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
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
I support this version of the document.
Tony Hansen
t...@att.com
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Internet Mail Architecture '
draft-crocker-email-arch-12.txt as a Proposed Standard
The
Ned Freed writes:
But that's the problem - this is not what RFC 5321 says.
It's not what 3501 says either ;) More of a one-sentence simplification
than a full and exact description.
...
SMTP server do stuff like expand lists all the time. For those tests
to be done competently some
s...@resistor.net writes:
If there isn't an authoritative reference and there are differences in
semantics or syntax between the draft and RFC5321/5322 or future
revisions of these documents, it can lead to serious issues.
Standards Track documents are around years. The documents may be
s...@resistor.net writes:
If there isn't an authoritative reference and there are differences in
semantics or syntax between the draft and RFC5321/5322 or future
revisions of these documents, it can lead to serious issues.
Standards Track documents are around years. The documents may be
At 20:21 01-03-2009, Dave CROCKER wrote:
As this draft is being considered as a Proposed Standard, will it
be authoritative instead of RFC 5821/5322?
This presumes that there are different semantics or syntax offered by them.
I'm replying to this point separately so that it does not get
For the content that overlaps in RFC5322 and RFC5321, which one is
authoritative?
d/
SM wrote:
At 20:21 01-03-2009, Dave CROCKER wrote:
As this draft is being considered as a Proposed Standard, will it be
authoritative instead of RFC 5821/5322?
This presumes that there are different
On Mon Mar 2 15:49:09 2009, Dave CROCKER wrote:
For the content that overlaps in RFC5322 and RFC5321, which one is
authoritative?
Whichever is cited by the document referencing the content, of course.
Alternately, we could have a public food fight between Klensin,
Resnick, and Crocker.
Dave Cridland wrote:
On Mon Mar 2 15:49:09 2009, Dave CROCKER wrote:
For the content that overlaps in RFC5322 and RFC5321, which one is
authoritative?
Whichever is cited by the document referencing the content, of course.
That sounds pretty unstable, since it produces context-dependent
At 20:21 01-03-2009, Dave CROCKER wrote:
What inconsistencies are you seeing, specifically, so we can fix them.
email-arch Section 2.2.2
The Relay performs MHS-level transfer-service routing and store-and-
forward, by transmitting or retransmitting the message to its
Recipients. The
At 20:21 01-03-2009, Dave CROCKER wrote:
What inconsistencies are you seeing, specifically, so we can fix them.
email-arch Section 2.2.2
The Relay performs MHS-level transfer-service routing and store-and-
forward, by transmitting or retransmitting the message to its
Recipients.
Maybe Dave you should add an Updates tag to your draft?
Eliot
On 3/2/09 5:26 PM, ned+i...@mauve.mrochek.com wrote:
At 20:21 01-03-2009, Dave CROCKER wrote:
What inconsistencies are you seeing, specifically, so we can fix them.
email-arch Section 2.2.2
The Relay performs MHS-level
ned+ietf-s...@mrochek.com wrote:
At 20:21 01-03-2009, Dave CROCKER wrote:
What inconsistencies are you seeing, specifically, so we can fix them.
email-arch Section 2.2.2
The Relay performs MHS-level transfer-service routing and store-and-
forward, by transmitting or retransmitting
On Mon Mar 2 16:05:16 2009, Dave CROCKER wrote:
Dave Cridland wrote:
On Mon Mar 2 15:49:09 2009, Dave CROCKER wrote:
For the content that overlaps in RFC5322 and RFC5321, which one
is authoritative?
Whichever is cited by the document referencing the content, of
course.
That sounds
At 07:49 02-03-2009, Dave CROCKER wrote:
For the content that overlaps in RFC5322 and RFC5321, which one is
authoritative?
There are several possible answers:
1. The author of the draft chooses the email-arch draft
2. The author of the draft chooses RFC 5321 and RFC 5332
3. Have the
At 10:10 26-02-2009, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Internet Mail Architecture '
draft-crocker-email-arch-11.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
SM wrote:
As this draft is being considered as a Proposed Standard, will it be
authoritative instead of RFC 5821/5322?
This presumes that there are different semantics or syntax offered by them.
What inconsistencies are you seeing, specifically, so we can fix them.
Again, we should note
More than a +1: it is about time we got this out. For example, we
would like to reference a document like this in the LEMONADE series of
documents.
That said, this particular document is well written, gets the point
across, and does the job nicely.
Of course, we could hold up publication
Since this is a substantive comment on a document that is in
Last Call for Standards Track, I'm posting the note to the IETF
list. Since I use different addresses for the SMTP list and the
IETF one, I don't know when or if this will appear on the latter.
With the exception of the last point,
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
At 8:30 PM -0500 2/27/09, John C Klensin wrote:
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.
+1. I
John C Klensin wrote:
What specific changes are you proposing?
Really, John, whatever folks agree on is more than fine with me. However, I
also note that some other experienced IETFers have indicated that they consider
it acceptable to leave the text as-is.
Please note that besides the
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
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Internet Mail Architecture '
draft-crocker-email-arch-11.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Internet Mail Architecture '
draft-crocker-email-arch-11.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
Tony Hansen wrote:
Should it be using RFC5321/RFC5322 instead of RFC2821/RFC2822, such as
RFC5322.From instead of RFC2822.From?
yes.
current draft came out just before the latest RFCs were published.
final publication will be revised (and nits fixed -- thanks for the close read.)
d/
--
36 matches
Mail list logo