[Top] [All Lists]

Re: 2822upd-04 definition of terms needed

2008-01-27 11:16:15

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.

Pete Resnick <>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102