Heads up: standards spring cleaning

Rik,

Just to make sure the IETF's EDI community knows about this.  Note that RFC1767, "MIME Encapsulation of EDI Objects" is on the list.

d/

--- Original Message ---
>  >Date: Mon, 06 Dec 2004 11:49:54 +0100
>  >From: Eliot Lear <[email protected]>
>  >To: [email protected], [email protected], [email protected]
>  >Subject: standards spring cleaning
>  >
>  >Good day,
>  >
>  >I am currently involved in an experimental process to see what it
>  >would take to hold to the notion that Proposed and Draft Standards
>  >shouldn't stay in that state forever.  There are a number of mail
>  >related standards that fall into this category, and I wonder if
>  >people can tell me whether the list of standards below (or any
>  >others on the broader list) should stay or go.  The original list
>  >was generated programmatically by looking for proposed standards
>  >below RFC 2000 that are not obsoleted (we'll do draft later).
>  >
>  >Here they are:
>  >
>  >RFC1421       Privacy Enhancement for Internet Electronic Mail: Part
>  >I: Message  Encryption and Authentication Procedures
>  >RFC1422       Privacy Enhancement for Internet Electronic Mail: Part
>  >II: Certificate-Based Key Management
>  >RFC1423       Privacy Enhancement for Internet Electronic Mail: Part
>  >III: Algorithms, Modes, and Identifiers
>  >RFC1424       Privacy Enhancement for Internet Electronic Mail: Part
>  >IV: Key Certification and Related Services
>  >RFC1494       Equivalences between 1988 X.400 and RFC-822 Message Bodies
>  >RFC1496       Rules for downgrading messages from X.400/88 to
>  >X.400/84 when MIME content-types are present in the messages
>  >RFC1502       X.400 Use of Extended Character Sets
>  >RFC1648       Postmaster Convention for X.400 Operations
>  >RFC1740       MIME Encapsulation of Macintosh Files - MacMIME
>  >RFC1767       MIME Encapsulation of EDI Objects
>  >RFC1848       MIME Object Security Services
>  >RFC1985       SMTP Service Extension for Remote Message Queue Starting
> >               (ETRN)
>  >
>  >If you believe any of the above standards should not be reclassified
>  >as historic, could you please send a note to
>  >[email protected] with the RFC number and a brief reason
>  >as to why not and whether the document should be advanced.  A good
>  >reason is that the standard is still generally useful.  A bad reason
>  >is that a piece of old code implements it somewhere on the 'net.
>  >That having been said we have a pretty low threshold for removing
>  >something from the above list.
>  >
>  >Thanks for your time,
>  >
>  >Eliot
>
>
>  --Paul Hoffman, Director
>  --Internet Mail Consortium




d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker  a t ...
www.brandenburg.com