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.