[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Another user-visible goal


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.