On 1/26/08 at 11:30 PM -0500, Bruce Lilly wrote:
2822upd-04 uses several terms in ways which may or may not conflict
with related specifications and documents;
Overall comment: For most of these, you're going to have to show me a
specific example of a conflict to convince me that any change needs
to be made. As I've said before to others, people can purposely
misread any specification we right, so I'm not inclined to try to
complicate things to try plug some perceived hole unless it's
actually going to stop someone who really wants to do the right thing
from doing something silly.
structured field bodies as used in section 2.2.2 and later;
specifically, is this definition meant to apply to (extension)
fields defined in other specifications?
I could put a note in 2.2.2, but I do wonder whether it would do much
to clarify things. Has anyone ever written an extension document with
a structured field where it wasn't clear if an implementation *that
implements the extension* should treat it as structured?
local time as used in section 3.3. Specifically, what is "local
time" if a (human) message composer is sitting in an airplane
composing a message via a telnet link to a (ground-based) host
computer which will then send the message via a separate, remote
submission server? [By the way, the airplane is crossing over the
(North) polar ice cap as the composer travels an intercontinental
great circle route to his destination.]
The DRUMS archive is replete with information on why this ambiguity
appears in this section, and your example actually points to the
reason: "local time" is whatever the implementation best thinks is
local time. It may make sense for certain specialized applications to
figure out what time zone it is in at the precise moment the message
is generated. For others, it might make sense to always use the
ground-based time of the host computer. The short answer is, this is
purposely ambiguous.
unlimited w.r.t. the number of optional-fields as specified in
section 3.6. Specifically, does it mean that the specification for
extension fields is not allowed to specify a maximum (or minimum,
for that matter) field count for extension fields?
Again, I'm curious where this might have ever caused confusion.
Anything strictly implementing (2)822(upd) better put absolutely no
limits on any optional-field. Anything implementing an extension
which gives a limit better honor that limit if it wants to conform to
that specification. I don't see how any sane person could point to
"unlimited" as a reason to ignore a MUST in another document.
creator as used in sections 1.2.3 and 3.6.1.
[...]
automatic (and related terms) as used in sections 3.6.3 and 3.6.6.
Common use. I see no issue here.
final form as used in section 3.6.1.
See discussion of local time above.
user as used in sections 3.6.1 and 3.6.6.
reply (and related terms) as used in sections 3.6.2, 3.6.3, and 3.6.6.
sender as used in sections 3.4 and 3.6.4.
reintroduced as used in section 3.6.6.
Flip answer: If you don't understand how these terms are being used,
you shouldn't be reading this document.
More serious answer: Definition of such things belongs in a serious
applicability statement on e-mail. I think it will only add possible
confusion points, not remove them.
pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102