Re: Comments on draft-klensin-email-i18n-message-00.txt

> To comment on one point, my assumption has been that, if we
> decide that the transaction encapsulation is useful and
> appropriate, we would just go to the effort to either move RFC
> 2442 to Proposed along with it, or would obsolete or update 2442
> and incorporate its key features into a revision of this draft.
> There are interoperable implementations of 2442. My
> retrospective guess as to why it was made Experimental

RFC 2442 is informational, not experimental. (I note in passing that one of the
author's names is misspelled in the RFC Index; I'll send in  a note about that
right away.)

> (I don't
> remember) is that the community wasn't convinced it was
> necessary and a good idea.  If we need it for this purpose, the
> question of necessity and desirability are immediately answered.

Informational status was chosen because that was the status deemed appropriate
for media type specifications at that point in  time. The reason don't recall 
any concerns that this wasn't a good idea is simple: There weren't any.
I clearly recall the meeting where I presented this specification,  and
I also recall that there were no objections or concerns raised. (The
reason I remember this so clearly is that I was quite surprised to encounter
so little resistance to the idea.)

Things have changed, and now the belief is that these sorts of registrations
belong on the standards track. But it goes without saying that such changes
in belief don't retroactivaly change the status of existing documents.

				Ned