On 4-jun-04, at 19:35, Steve Hole wrote:
1. Paper mail doesn't have to be the reference model to follow (or
to selectively avoid following).
Indeed. Quite the opposite: we have more than enough experience with
real one-to-one, one-to-few and one-to-many email, usenet/echomail,
instant messaging and web-based content publishing to be able to
disregard postal mail as a reference model. (Although it never hurts to
scavenge it for useful features that aren't available in electronic
communication yet.)
2. The US model for paper mail is not the only one.
Huh? Envelope, stamp, mailbox/hole in the door/wall, isn't all of this
pretty muchc the same thing world wide?
3. The words "envelope", "header" and "body" do not contribute to
worldwide understanding.
Are there any words that mean the same thing worldwide?
It is potentially dangerous to reuse terminology and concepts from a
single paper based postal model -- for all the reasons stated:
limitations in thinking, assumption of common context and confusion
over reused terms with different semantics.
Right, so let's not do that.
But, you have to start somewhere. In particular refering to one or
more existing models is perfectly acceptable as long as we keep the
warning fully in mind.
A good place to start would be existing email. The new stuff should
support all legitimate uses of existing email and a good number of the
extra features that have been discussed here.
Also, any use of terminology in the end system must be fully defined
to avoid any reuse inconsistency.
Definitions are useful for technical specifications but not for
"normal" text that must be parsed in a single go and/or by people who
don't implement protocols. Acting like Humpty Dumpty doesn't make for
useful communication. (Just in case:
http://sundials.org/about/humpty.htm )
From a philosophical standpoint it would be a good idea to look at all
of the available existing models (paper and electronic) and select
those characteristics that apply, are obviously useful, that work and
that have strong analogy with the target electronic model.
I appreciate the great value the IETF places on architecture, but in
reality architecture is mostly an implementation detail. The features
are the real issue. There are some important architectural choices to
be made in the protocol itself, but these should follow from the
features we want to support rather than the other way around. Going
back to the original topic: in existing email the difference between
envelope, header and body is both very distinct (envelope is
transmitted apart from the header/body, and these two are separated by
the first empty line) and hopelesly convoluted because of the way
envelope and header data are represented as the other and the lack of
different header types. The required feature of being able to sign
messages clearly requires that there is absolute certainty in
distinguishing between unmodifyable end-to-end headers and headers that
may be added and even changed in transit.
Specifically, what elements of the UK or African or whatever model
would make sense in the electronic model?
One interesting aspect here would be the dreaded character set issue.
Apparently it's possible to send letters to Russia or Japan that are
addressed in the latin character set even thouth that's not the native
character set there. How do they solve this issue in the postal system
in those countries?
Because we do need to provide labels for the concepts, is there an
alternative to "envelope" that is better? It is an english word with
quite a specific meaning. Perhaps "package"?
Hm, so the SMTPNG protocol would have the SMYP command (Show Me Your
Package)?
I think if we want to make progress in this area it would be good to
come up with examples of information that can come up in an electronic
message and describe this information (modifiyable in transit, data
format, optional/mandatory, that kind of thing) and then see if there
is an obvious way to group them.