IPP Mail Archive: Re: IPP>NOT mailto feature from IETF meeti

Re: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -TheIPPNotification I-Ds will now go the IESG)]

From: ned.freed@innosoft.com
Date: Fri Aug 18 2000 - 12:55:50 EDT

  • Next message: Manros, Carl-Uno B: "RE: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -TheI PPNotification I-Ds will now go the IESG)]"

    > > Then, when NOTARY, with its structured report format came out...

    > Can you give us a very brief summary of what NOTARY is, and perhaps
    > a pointer or two to some online info?

    NOTARY was an IETF working group that worked on the general problem of
    (non)delivery notifications for Internet mail. The group ended up standardizing
    a bunch of stuff:

    (1) A standard report MIME multipart subtype that can be used for all kinds
        of notifications. The key feature of this format is that it contains
        both a human readable part and a machine readable part.

    (2) An elaboration of (1) specifically intended for (non)delivery
        notifications.

    (3) An SMTP extension that lets message originators specify what sort of
        notifications they want back (including notification of successful
        delivery) as well as additional information that makes the content of
        notifications more meaningfui and useful.

    (4) A more precise set of error codes for SMTP.

    (5) A mechanism for embedding such codes in SMTP responses.

    See RFCs 1891-1894 for the specifics. (1) is really the relevant piece to IPP;
    RFC 1892 describes it. This format has been used for things besides NOTARY
    since it was developed; see RFC 2298 for an example.

                                    Ned

    P.S. NOTARY is implemented by almost all modern MTAs, so support for it is very
    widespread. (I'm not sure we can take credit for this -- the need to update
    MTAs to block message relay is likely more responsible for the infrastructure
    upgrade that NOTARY was.) And while some aspects of NOTARY, especially (3),
    made implementation somewhat tricky, AFAIK the new format was not found to be
    hard to support.



    This archive was generated by hypermail 2b29 : Fri Aug 18 2000 - 15:29:58 EDT