ietf-smtp
[Top] [All Lists]

Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian

2012-02-28 21:14:52


ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
> ... but as it happens there is a pretty clear and simple model for
> the semantics that attach to bcc. We didn't come up with it - in fact
> it goes
> all the way back to typewriters and hand manipulation of copies and
> the carbons
> between them - but it's a model nevertheless. And many if not most of the
> technical details of how you implement this stuff follow directly from
> this
> model.

X.400 documented this pretty clearly. If we're going to discuss a model
for Internet Mail, it'd be worth at least using that as a starting point.

Gonna have to disagree with you there. Having spent literally hundreds of hours
poring over the X.400 documents and having done complete implementations of
both X.400-1984 and X.400-1988, yes, the documents expand a large number of
words documenting something they called a model, but the term "clear"
definitely did not apply. If it had then none of the various operational
profiles of X.400 like GOSIP (which added another three inch of paper to the
pile) would have been wanted or needed.

And even in the parts that were clear, they got an appalling number of details
either flat out wrong or made them dependent on deployment of other services
that was never going to happen. A good example of the former is the X.400
approach to media types - if you think our media type system has issues try
building one that names things with random OIDs and which imposes no
serialization requirement. (Every media type in X.400 is allowed to define it's
own ASN.1 structure and you have to know that structure to interpret it
properly.) To its credit, the EMA was working to address these issues by
setting up a registry and disallowing all but the use of a single octet string
to store the content, but X.400 faded away before any of that could be
implemented.

A good example of the latter is how read receipts in X.400 depend on being able
to correlate envelope and header addresses. That effectivey presumed the
existence of a global white pages service that allowed read access to
everyone's aliases, which pretty obviously was a nonstarter from the get-go.

In the specific case of the bcc model in X.400, my copies of the specifications
are at work so I cannot check them, but if memory serves the model, while being
fairly clear for once, called for this to be handled as part of P3 (the X.400
equivalent, more or less, of SUBMIT). In practice this was problematic if for
no other reason than P3 was rarely if ever implemented, so the semantics it was
supposed to provide didn't actually exist in most real world systems.

Another issue was the X.400 equivalent of the issue Randy brought up with "for"
clauses. In X.400 when a message is split information about all recipients is
retained in both message copies; the information for recipients in the other
copy is just marked inactive. The implications of that should be obvious. And
the rules in the model for when this information was supposed to be dropped
were ... unclear to say the least.

Anyway, I really need to stop remembering this stuff before, as they say, any
more of my gray cells hit the bug lamp.

                                Ned