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

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

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

From: Jay Martin (jkm@underscore.com)
Date: Tue Aug 15 2000 - 14:57:30 EDT

  • Next message: Manros, Carl-Uno B: "IPP> New PROPOSED STANDARD document for publishing as RFC - Internet P rinting Protocol (IPP): LDAP Schema for Printer Services <draft-ietf-ipp- ldap-printer-schema-03.txt>"

    Bob,

    > From: pmoore@peerless.com [mailto:pmoore@peerless.com]
    > Sent: Monday, August 14, 2000 2:55 PM
    >
    > First - we all agreed not to do it. This seems like a good reason not to do
    > it.
    >
    > [rgh reply]
    > I concur that at the last meeting we did agree not to have a Machine
    > Consumable format in 'mailto'. However, earlier this year we were going in
    > the opposite direction and tried to get a Machine Consumable format to work
    > in 'mailto'. We seemed to give up because the solutions were too complex.
    >
    > When I discovered this simple solution, I thought it would be good to find
    > out if PWG member are opposed to a Machine Consumable format regardless of
    > the solution or are opposed only to complex solutions.

    With all due respect, might I suggest you go back and read the *rest* of
    Paul Moore's response and address the many other concerns he so clearly
    stated. (I've attached Paul's msg for your convenience.)

    IMHO, Paul asks the best question of all:

    > Again I ask what the purpose is? Is the idea to enrich the end user experience
    > or is it an attempt to overcome the 'INDP wont go through a firewall' issue.

    Why do you feel we need machine-readable components in an email msg?

    I know for a fact that I am not alone in being totally confused about
    the real-world requirements for dynamic/binary data vs. simple textual
    email for printing notifications. Why would anyone would *demand* relatively
    real-time notifications for print jobs outside of a firewall, anyway?
    (God only knows such a person would never PAY for software that does this,
    right? ;-)

            ...jay

    attached mail follows:


    First - we all agreed not to do it. This seems like a good reason not to do it.

    Second, what is the point of machine-readable email? To whom did it get sent?
    There is some mention of a browser plug-in - I along with many people - dont use
    a browser to read my mail. Presumably the 'plug in' would read the email ver my
    shoulder and then proceed to tell me what the human readable portion of the
    mail told me anyway. So now I get the same message twice. Whats the point? I
    have to install software on every client - the only purpose of which is to
    repeat a message

    If the email gets sent to some other mail box - how does this get set up? In
    general I cannot just (as a client) invent a new mailbox name - that is the
    whole point about stire and forward mail systems.

    Again I ask what the purpose is? Is the idea to enrich the end user experience
    or is it an attempt to overcome the 'INDP wont go through a firewall' issue.

    I agree that in many cases INDP wont go through a firewall - but I dont see that
    as an issue in real life. I send a job to Kinkos (or wherever), they send it to
    one of their printers, the real printer tells the Kinko print system when it has
    finished (possibly via INDP), the Kinkos print system sends me a piece of email
    telling me that it has finished. I dont see any piece missing from this
    solution.

    But what the heck, lets make it a little more complex. Plus make sure we
    distribute the flame-proof underwear to users who end up asking for page
    notifications via email.

    "Herriot, Robert" <Robert.Herriot@pahv.xerox.com> on 08/14/2000 02:20:20 PM

    To: "Manros, Carl-Uno B" <cmanros@cp10.es.xerox.com>, IETF-IPP <ipp@pwg.org>
    cc: (bcc: Paul Moore/AUCO/US)

    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
    added.

    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
    parameter.

    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
    message.

    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
    fields.

    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;
        boundary="simpleBoundary",
        report-type=application/ipp,
        report-content=ipp-notify

    --simpleBoundary
    Content-Type: text/plain

    Printer tiger has stopped with a paper jam.
    --simpleBoundary
    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
    <charset>attributes-charset,us-ascii
    <natural-language>attributes-natural-language,en-us
    <event-notification> ; tag for Event-Notification Attributes Group
                        ; each line below contains a syntax type,
                        ; an attribute name and an attribute value
    <integer>notify-subscription-id<123>
    <uri>notify-printer-uri,tiger
    <keyword>notify-subscribed-event,printer-stopped
    <integer>printer-uptime<12345>
    <integer>notify-sequence-number<48>
    <charset>notify-charset,us-ascii
    <natural-language>notify-subscribed-event,en-us
    <octet-string>notify-subscribed-event<>
    <text>notify-text,Printer tiger has stopped with a paper jam.
    <enum>printer-state<stopped>
    <keyword,printer-state-reasons,media-jam
    <boolean>printer-is-accepting-jobs<true>
    <end-of-attributes> ; end of attribute tag

    --simpleBoundary

    ------------------------------------------------------

    The full details are at
    ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-mailto-000811-rev.doc
    ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-mailto-000811-rev.pdf
    ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-mailto-000811.txt



    This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 15:11:59 EDT