Dave CROCKER wrote:
Vijay,
Many thanks for the detailed review.
No problem; it was fun to read the draft on a technology used
everyday.
More inline.
I've added:
"There is no formal limit to the number of names in the sequence --
that is, to the depth of the hierarchy -- nor any standard semantics
to the depth."
Is that sufficient?
Yes, perfect.
The table is for places that list /identifiers/, rather than
/labels/. MIME does not have any identifiers.
However you are not the first to ask about listing MIME in the table,
which means that it might help to add text that clarifies or
emphasizes this point, but I'm not exactly sure what to suggest.
(For reference, since MIME is content, it's the author's MUA that
creates it.)
How about: s/Author/aMUA? That would solve it (at least from
my perspective.)
Same comment for RcptTo and ORCPT: Do Authors set this or does the
MTA or MDA?
Your query prompted me to chat with a few email folks. One point
that might make the table a bit clearer is that "Set by" is meant to
refer to who determines the value, rather than who creates the field.
Ah ... so how about putting this as a comment; i.e.
OLD:
| Layer | Field | Set By |
NEW:
| Layer | Field | Set By (Who determines |
| | | (the value that goes in |
| | | the field.) |
Feel free to edit.
The author sets the RcptTo. Otherwise, none of the following modules
would know where to send the mail.
Sure; this makes more sense now that I know who determines the
value that goes in the RcptTo field.
ORCPT turns out to be more interesting. Based on the additional
discussions, I now believe the table should indicate that it is the
Originator that sets the value. At base, its a handling audit field,
which fits nicely into the Originator's role.
Thanks for probing this.
Sure; glad to help ;-)
5) S4.3.2, page 31: "The primary routing mechanism for Internet
Mail is the DNS MX record..." My comment is: is the DNS MX record
a service lookup mechanism or a routing mechanism? I believe it is
the former (i.e., a service lookup mechanism) and not the latter.
[...]
So I tossed the text into the draft, and waited to see who got
heartburn from it. In fact, I believe you are the first to comment
on it.
Oh! If you think that is fine, then I am okay. I will defer to
your judgment here.
6) S3.1, first paragraph, the last two sentences: "Formal Internet
... [RFC2821].". My question is, if source routing has been
deprecated, why mention it at all?
(You should ignore the hand that is waving as I type this...)
Lots of folk don't realize it's deprecated, and it was around
formally for a long time, though not all that usefully. So the intent
of including it is to help mark the change.
OK.
8) S3.1, page 17, first paragraph on that page: this paragraph does
not read well. It contains a mish-mash of a run-on sentence and
gratuitous capitalization in the first sentence. May be wise to
reword it.
So, how's this:
Old:
[...]
New: Basic email addressing defines the <local-part> as being
globally opaque. However there are some uses of email that add a
standardized, global schema to the value, such as between an author
and a Gateway. The <local-part> details remain invisible to the
public email transfer infrastructure, but provide addressing and
handling instructions for further processing by the Gateway.
Standardized examples of such conventions are the telephone numbering
formats for VPIM [RFC3801],such as:
Sure; works for me. One typo in the last line -- s/],such/], such/
Thank you.
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: v...@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
