On Fri January 28 2005 11:07, Charles Lindsey wrote:
In <200501271357(_dot_)34152(_dot_)blilly(_at_)erols(_dot_)com> Bruce Lilly
As a result of our discussion starting July 15, 2004, I
have prepared an Internet Draft; draft-lilly-from-optional-00.txt
should be available from the usual places [*]. Public comments
may be posted to the ietf-822 list; private comments to the
author are also welcome.
I have several problems with this.
1. Is it really necessary to modify RFC 822 and well as RFC 2822?
This memo (if approved) updates the Internet Message Format
specification [N1.STD11], [N2.RFC2822] as used by various
applications (electronic mail [I3.STD10], [I1.RFC2821], Usenet news
[I4.RFC1036], Internet fax [I5.RFC2305], VPIM [I6.RFC3801], EDI
[I7.RFC1767], [I8.RFC1865], etc.). It applies across the board to
applications using the Internet Message Format. However it does not
discuss similarly named fields in unrelated formats and protocols
such as [I9.HTTP] or [I10.SIP].
I think it is most unwise to attempt to impose this change on
protocols/applications other them electronic mail without first consulting
the working groups of other bodies responsible for those protocols.
It imposes no changes on protocols/applications other than those
that use the Internet Message Format. The quoted text above clearly
and specifically says so. As for WGs and "other bodies", there
is certainly opportunity for comment now, as well as at the
time of a Last Call prior to submission for publication.
In the case of Netnews, in particular, I would regard this proposal as
totally unacceptable, since it is clearly desirable and widely expected
that it will be possible to identify the (claimed) poster of any Usenet
article, even if only by the pseudonym that poster chooses to be known by.
That is certainly possible via a number of existing mechanisms
(From field with an "effective and useful for replies" [RFC 2821
section 3.8.4] mailbox, a standard Comments or Organization (for
Usenet specifically) field w/o a mailbox, or indication in the
body of the message), or an extension field which is not an
address field could be defined. Making the From field optional
for the purpose of permitting anonymity and to appropriately
handle the case of an author with no Internet mailbox any of
those mechanisms which do not require an effective and useful
I would sugges that, for Usenet, at least the display name should be
provided when no email address is available. That would leave the
Allow the <mailbox> to be omitted when <display-name> is present.
Allow some form of dummy <mailbox>, such as '<>'.
No, in the From field that would be incompatible with long-standing
field syntax specifications, as specifically discussed in the draft
and as discussed here (specifically including "<>" and syntactically
legal but semantically empty alternatives) this past Summer.
Encourage the use of clearly unresolvable domains, such as those
ending in '.invalid'.
Unresolvable domain names present problems for DNS, as discussed here
in July, where that (".invalid") proposal was called a "showstopper".
In light of the "SiteFinder" debacle (see the reference in the draft),
that's a serious matter, since it's not always possible -- on the
Internet -- to distinguish a non-existent domain; it certainly might
be impossible off the Internet, such as on the non-Internet side of
It is, in
any case, not clear that some existing user agents will not barf at the
proposed total absence of the From header.
Well, they certainly won't be able to compose responses to the
author, but (as discussed in the draft) that is not something
that one could do for the case of an anonymous author or an
author with no Internet mailbox, which are the cases covered
by the draft.
Some documents have suggested use of the reserved ".invalid" TLD
(top-level domain name) [I18.BCP32] to provide some degree of
anonymity. With relaxation of the requirement for a From field in
the Internet Message Format, such hacks and their negative impact on
the root name service are unnecessary, at least within the scope of
That reference to "hacks" and "negative impact" is hardly fair.
It is based on the discussions here in July. At the moment,
the two RFCs that do so are SIP documents, which is specifically
outside of the scope of the draft; however making the From field
optional would obviate any tendency to repeat such a mistake in
the messaging area.
been assured by people who understand the DNS system better than I do
that it is a common and recommended practice for DNS failures to be
If it were a common practice, there wouldn't be an RFC (2308)
lamenting the lack of such optional caching of negative responses
in practice. Moreover, if that practice were in fact widespread
on the Internet, it would not help in the case of inappropriate
positive responses (as in the SiteFinder debacle), nor would it
help systems not directly connected to the Internet (as in
offline message composition, and non-Internet and/or non-mail
systems which make use of a gateway for sending to Internet
Moreover, '.invalid' can, and should be,
built into agents so that they do not waste time even trying.
Absolutely not; RFC 3696 specifically discusses such nonsense --
the only way to determine if a hypothetical domain name is
valid is to query DNS. Building special hardwired cases into
code has caused, and can be expected to continue to cause,