IPP Mail Archive: IPP>NOT another look: refined solution to

IPP Mail Archive: IPP>NOT another look: refined solution to

IPP>NOT another look: refined solution to mailto feature (from to day's IPP telecon)

From: Herriot, Robert (Robert.Herriot@pahv.xerox.com)
Date: Wed Aug 16 2000 - 17:11:11 EDT

  • Next message: Carl Kugler/Boulder/IBM: "Re: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM - The IPP Notification I-Ds will now go the IESG)"

    At today's IPP telecon we discussed the 'multipart/report' feature that I
    proposed for the 'mailto' Delivery Method. (The details of the original
    proposal are repeated at the end of this email message.)

    There were strong feelings on both sides. The telecon compromise was to
    change the entire proposal (the 'multipart/report' feature and the
    accompanying "notify-mailto-report" attribute) from required to optional.
    This change requires an additional optional "notify-mailto-report-supported"

    If the "notify-mailto-report-supported" attribute is not present in the
    Printer or has a value of 'false', the Printer does not support the
    "multipart/report" feature. If the "notify-mailto-report-supported"
    attribute is 'true', the Printer supports the "multipart/report" feature.

    Someone in the telecon stated that this compromise is the "ecumenical
    solution". This compromise allows those who believe in this feature to
    implement it. Everyone else can ignore it. Furthermore, it ensures
    interoperability for vendors who decide to add this feature some time in the

    We are now soliciting comments about this proposal from the DL.

    Bob Herriot


    -----Original Message-----
    From: Herriot, Robert [mailto:Robert.Herriot@pahv.xerox.com]
    Sent: Monday, August 14, 2000 2:20 PM
    To: Manros, Carl-Uno B; IETF-IPP
    Subject: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM - The
    IPP Notification I-Ds will now go the IESG)

    At the recent IETF meeting Ned Freed (our AD) asked whether we could send
    machine readable information with the "mailto" Delivery Method. He
    suggested that "mulipart/report" could be used to send machine readable
    information, and he left it to the IPP WG to decide whether such a feature
    should be added. I then worked out a very simple design using Ned's ideas.

    A use scanario is a browser with a plug-in which uses IMAP or POP3 to get
    and display email that represents Printer Event Notifications (the plug-in
    uses the Content-Type to separate the email).

    So I am asking the IPP WG two questions (please respond to the DL):

       1) Should we augment the "mailto" Delivery Method so that it can send
          Machine Consumable information. That is, does it add value?

       2) If so, is the proposed solution acceptable?

    Before answering these qustions, please read a quick summary of the solution
    below. The solution is very simple. The text in the spec leverages existing
    features and I expect the code would too. The URLs of the changed document
    are at the end of this discussion.


    A new Subscription Template attribute "notify-mailto-report (boolean)" is

    When its value is 'false' the Printer behaves as it did before this
    attribute was defined.

    When its value is 'true', the Printer sends a message body whose
    Content-Type is 'multipart/report'. According to the definition or
    'multipart/report'(RFC 1892), the first body part of the 'multipart/report'
    contains the Human Consumable information and the second body part contains
    the Machine Consumable body part. So, the first body part contains whatever
    the entire message body would contain if the value of the
    ""notify-mailto-report" were false. The second body part contains the
    message body of a Send-Notifications request for the indp Delivery Method.

    The Content-Type contains two parameters: the RFC specified parameter
    "report-type=application/ipp", and a new parameter
    "report-content=ipp-notify". A browser plug-in can search for the latter

    A Printer MUST support the "notify-mailto-report" attribute and the default
    is "false". Thus there is no need for "notify-mailto-report-default" and
    "notify-mailto-report-supported" attributes. Furthermore the code to support
    this feature is a trivial combination of the indp and Human Consumable
    mailto code.

    Below is an example taken from the spec:


    When the Printer jams, the Printer generates and sends the following email
    The Machine Consumable body part below is represented in a symbolic manner
    with the following characteristics:

    a) Fields that specify length of the following attribute name or value are
    not shown

    b) Other binary data is enclosed in angle brackets with the symbolic name or
    2 hex-digits per octet.

    c) Commas separate fields when an angle bracket is not present to delimit

    d) The '<>' mean empty octet-string

    e) Comments occur between the ';' and the end of the line.

    Date: 29 Aug 00 0832 PDT
    From: tiger <printAdmin@abc.com>
    Subject: printer: 'tiger' has stopped
    To: pwilliams@abc.com
    Content-type: multipart/report;

    Content-Type: text/plain

    Printer tiger has stopped with a paper jam.
    Content-Type: application/ipp

    <0101> ; Version 1.1
    <001D> ; operation Send-Notifications
    <00000000> ; request-id
    <operation-attributes> ; tag for operations attributes
                                    ; the 2 lines below contain a syntax type,
                                    ; an attribute name and an attribute value
    <event-notification> ; tag for Event-Notification Attributes Group
                                    ; each line below contains a syntax type,
                                    ; an attribute name and an attribute value
    <text>notify-text,Printer tiger has stopped with a paper jam.
    <end-of-attributes> ; end of attribute tag


    The full details are at

    This archive was generated by hypermail 2b29 : Wed Aug 16 2000 - 17:20:02 EDT