(Document Shepherd Tony Hansen added.)
Vijay,
Many thanks for the detailed review.
Responses to the questions and substantive points:
Vijay Gurbani wrote:
3) S3.3, towards the end of first paragraph: do you think it is worth
mentioning here that people should not derive any specific connotation on
enterprise organization by counting the number of dots in the FQDN. I have
seen many academic papers do this. Essentially, the number of dots does not
matter in a DNS name.
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?
(The goal of the section is to offer the briefest summary possible, while still
being useful for the email-arch discussion.)
4) Table 1: Is the MIME header set by an Author or a MUA? Most MUAs
automatically set the MIME header type depending on the configuration of the
MUA; in other words, most commercial MUAs are configured to utter the right
MIME type when they encounter a certain filename. I have not seen email
authors physically set a MIME type unless they are attaching a file for which
no predefined MIME type exists.
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.)
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. For Rcpt-To, the
author specifies the list of recipients, but it's the Originator who fills out
the form, since it performs the direct protocol actions. The purpose of the
table is really about authority over a value, so it needs to reflect who makes
the information decision, rather than who performs some mechanics.
The author sets the RcptTo. Otherwise, none of the following modules would know
where to send the mail.
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.
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.
FWIW, this bit of text has often generated some controversy, over the couple of
decades I've used it. It is the fact that it supports -- and was actually
motivated by the need for -- indirect transfer, by relaying through an
intermediary, that is the basis for my own comfort with viewing it as a routing
protocol. (There's probably a case even if it were only direct, but that would
be a lot less interesting.)
And, indeed, I'm not the only one with that view:
<http://en.wikipedia.org/wiki/MX_record>
"An MX record or Mail exchanger record is a type of resource record in the
Domain Name System (DNS) specifying how Internet e-mail should be routed"
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.
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.
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:
A few types of addresses elaborate on basic email addressing, with a
standardized, global schema for the <local-part>, Include are
conventions between authoring systems and Gateways. They are
invisible to the public email transfer infrastructure. When an
Author is explicitly sending through a Gateway out of the Internet,
coding conventions for the <local-part> allow the Author to formulate
instructions for the Gateway. Standardized examples of such
conventions are the telephone numbering formats for VPIM [RFC3801],
such as:
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:
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
