Re: Let's make a decision this March

[Einar Stefferud <Stef@xxxxxxxxxxx>]

Hello Greg, et al ---

Since I must attend the NIST OIW during the week of the IETF in STL, I
feel a bit disenfranchised by your process.  It seems to me that I
have made many arguments and contributions to this discussion, and now
it appears that I must also go in person to STL to argue my case, or
restate it all yet again in a fresh contribution.

I would prefer to refer you back to all my messages in this
discussion.  Just search for From: Stef in the transcript -- my
contributions have not been too long winded, or too numerous.

So, I will "vote" in this message, and will give you definitive
responses on each, but without regurgitating the whole story.  My
intent is to be positive and constructive in my response.

> Let me frame the question and discussion.

> 1) Should this effort be pursued in light of the pending deployment of
>    X.400?

Yes, but in coordination with the X.400 standards, such that we can
map X.400 body-parts to RFC822++ "body-parts", and vice versa.  I
would follow the lead given by Steve Kille, and relate all this to the
X.400 gateway situation.

I see no reason to go off on a tangent to define multi-part,
multi-media RFC822++ objects that are knowingly incompatible with, and
un-mappable with, X.400 objects.

But, I do see lots of reasons to find ways to extend RFC822++ to carry
the same kinds of objects, just because we need to progress in this
direction, and waiting for everyone to get X.400 first is not tenable.

I am not concerned with whether this speeds or slows X.400 deployment,
inside or outside the "Internet".  X.400 systems should compete openly
with their alternatives, and we should not handicap easily deployable
RFC822++ capabilities in the interests of "helping X.400".

What we need is coexistence and a smooth transition path between the
two realms.  (I think REALM is the right word here.)

> 2) If we do extend	 the suite of Internet Message protocols to handle
>    multi-media and extended character sets, should this be done solely
>    in a RFC 822 follow-on document, or should it include a backwardly
>    compatible upgrade to SMTP?

Solely with an RFC822++ document, with no changes to SMTP, just
because it can be done without any changes to SMTP, and because the
only extra benefit that I can see is reduction of some bandwidth in
some cases, at the cost of widespread disruption of the current
"internet mail realm".

> 3) What, if any, will the general framework of the encoding scheme be?

I would hope that Nathaniel Borenstein's schemes for handling
multi-media objects inside RFC822 can be used as the base for carriage
of structured bodies, preferably using RFC934 style recursive object
boundaries (vice using RFC1154 style character of line counts), though
I am not sure yet that Nathaniel's schemes are well enough served by
the RFC934 style.  It is only the style that I advocate, though it
would have been nice if RFC934 could have carried the freight.

I would also recommend finding and adopting an 8-bit => 7-bit mapping
that will allow carriage throughout the entire internet mail realm,
including UUCP and BITNET.

I am not going to worry about GATEWAYS to systems like PROFS, cc:MAIL,
et al, in that those systems own the problems of interfacing to the
internet mail realm, and not vice versa.  I suggest that each such
proprietary mail system should carefully define a gateway for their
use in attaching to the internet mail realm.  This suggestion is based
on the same logic that caused us to develop RRC987/1148/etc as
INTERNET specifications for how to connect the INTERNET MAIL REALM to
the INTERNATIONALLY STANDARDIZED X.400 REALM.

> Note:  Point 2 is very narrow.  I consider it a show stopper to make
> any change to SMTP which is not backwardly compatible with current
> SMTP. 

I agree.  

>>>>>>>>  Best...\Stef

------- End of Unsent Draft