Re: 2822upd-04 definition of terms needed

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