IPP Mail Archive: RE: IPP> notification methods [XHTML 1.0 i

IPP Mail Archive: RE: IPP> notification methods [XHTML 1.0 i

RE: IPP> notification methods [XHTML 1.0 in 'mailto:']

From: don@lexmark.com
Date: Thu Jul 27 2000 - 11:11:51 EDT

  • Next message: McDonald, Ira: "RE: IPP> notification methods [XHTML 1.0 in 'mailto:']"

    Interesting idea but XHTML 1.0 does not address the need for machine readable
    and by implication machine "actionable" notifications.

    **********************************************
    * Don Wright don@lexmark.com *
    * Chair, Printer Working Group *
    * Chair, IEEE MSC *
    * *
    * Director, Strategic & Technical Alliances *
    * Lexmark International *
    * 740 New Circle Rd *
    * Lexington, Ky 40550 *
    * 859-232-4808 (phone) 859-232-6740 (fax) *
    * (Former area code 606 works until 10/1) *
    **********************************************

    imcdonald%sharplabs.com@interlock.lexmark.com on 07/26/2000 08:27:24 PM

    To: imcdonald%sharplabs.com@interlock.lexmark.com,
          pmoore%peerless.com@interlock.lexmark.com
    cc: ipp%pwg.org@interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark)
    Subject: RE: IPP> notification methods [XHTML 1.0 in 'mailto:']

    Hi folks,

    Just talked to Hugo Parra for awhile about the following
    idea:

    Since the IPP 'mailto:' notification delivery method
    by default (as it should) permits IPP Notification
    generators to add one or more MIME attachments
    (machine-readable parts), interoperability is only
    possible if we recommend a default MIME type for the
    machine-readable content.

    I propose XHTML 1.0 (HTML 4.0 in written as 'well-formed'
    XML 1.0) - support is widespread in EXISTING email
    infrastructure and email clients - the presentation
    and the content can be rich and transform elegantly
    (even without style sheets like CSS or XSL).

    Because EXISTING email infrastructure and clients do
    NOT have support for the MIME type 'application/ipp'
    I will go out on a limb and say we should recommend
    that IPP notification generators do NOT include it
    as a MIME attachment in IPP email notifications.

    I will now don my flame retardant clothing and breathing
    mask...

    Cheers,
    - Ira McDonald

    -----Original Message-----
    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Wednesday, July 26, 2000 4:27 PM
    To: 'pmoore@peerless.com'; McDonald, Ira
    Cc: 'ipp@pwg.org'
    Subject: RE: IPP> notification methods

    Hi Paul,

    Actually, Tom Hastings pointed out today that the
    current version of IPP 'mailto:' (which is in 'last
    call') has machine-readable notifications (in ADDITION
    to the human-readable always required) as the DEFAULT
    because the boolean 'notify-mailto-text-only' defaults
    to FALSE (i.e., attachments are permitted at the
    discretion of the IPP Notification generator, the
    Printer or ENS).

    An IPP Client must SUPPRESS machine-readable content
    by requesting 'notify-mailto-text-only=TRUE' at
    Subscription creation time.

    I'm content with this - in the future, if we deem it
    advisable, we can decide that 'application/ipp' is
    RECOMMENDED as (one of) the MIME attachments in all
    machine-readable IPP 'mailto:' notification messages.

    Cheers,
    - Ira

    -----Original Message-----
    From: pmoore@peerless.com [mailto:pmoore@peerless.com]
    Sent: Wednesday, July 26, 2000 9:56 AM
    To: McDonald, Ira
    Subject: RE: IPP> notification methods

    You describe one of the many great applications for machine readable
    notifications (we think they are very important too).

    We decided not to do machine readable email - I dont think anybody wants to
    open
    that can of works again (the main reason though is that machine readable
    email
    is not very human readable and must not be localized - the printer would
    have to
    know whether it was emailing a program or an end user). We also discussed
    attaching a application/ipp body that had the machine readable form - but
    gave
    up on the idea. Not least because some of the high traffic machine readable
    messages (page events) would swamp an email system (imagine the email virus
    checker running on every page notification event!)

    In the environment you describe INDP will work perfectly. If there is an IP
    infrastructure that allows LPR to pass through then why not INDP - its just
    IP
    traffic on a different port (going the other way)

    "McDonald, Ira" <imcdonald@sharplabs.com> on 07/26/2000 09:45:14 AM

    To: "'harryl@us.ibm.com'" <harryl@us.ibm.com>, "McDonald, Ira"
          <imcdonald@sharplabs.com>
    cc: ipp@pwg.org, pmoore@peerless.com (bcc: Paul Moore/AUCO/US)

    Subject: RE: IPP> notification methods

    Hi Harry,

    Here's a killer app for machine-readable email notifications:

    A gateway from a customer's existing LPR-based print spooling
    (for mixed operating systems, the single most widely deployed
    environment) to a bunch of new IPP printers.

    To generate a high-quality (localized) LPR email notification
    for jobs, this gateway application MUST get IPP machine-readable
    notification and email infrastructure is cheap and deployed.

    On IPP notification only via email in Internet (practical but
    limited if no machine-readable):

    IPP has a set of attributes and attribute semantics. The IETF
    approved mandatory notification method that gets added to IPP
    is going to live or die by conveying full IPP semantics.

    Human-readable email CANNOT convey full IPP semantics as presently
    conceived (too much server-side new localization is needed for
    attribute names and attribute keyword values, for example).

    Cheers,
    - Ira

    -----Original Message-----
    From: harryl@us.ibm.com [mailto:harryl@us.ibm.com]
    Sent: Wednesday, July 26, 2000 8:07 AM
    To: McDonald, Ira
    Cc: ipp@pwg.org; pmoore@peerless.com
    Subject: RE: IPP> notification methods

    Oohhh! This gets really sticky! I thought the ONE thing we had (mostly)
    all agreed on was to not carry machine readable in e-mail. I think most of
    the reviewers of the multitude of notification proposals fundamentally see
    mailto as a sure fire way to get a human readable notification across the
    Internet in need be and INDP as the preferred machine readable method
    (thus Paul's recommended intuitive convention or mandate - mailto/human vs
    indp/machine).

    INDP is not an intranet-only solution (as recently pointed out by Don).
    Albeit specific configuration is required. I think the argument, here, is
    that nothing really works without someone pulling the strings. What we
    view as "standard" holes in firewalls exist only because someone deemed
    these necessary and appropriate to facilitate a meaningful experience on
    "the web".

    I tend to disagree with....
    >And a MUST solution for the Internet proper that can't
    >convey the full 'application/ipp' semantics is going to
    >fail approval by the IETF.

    Today the IETF has approved IPP with no notification. If we
    later define "must support e-mail with text" I'm not
    sure why this should "fail".

    If your prophecy is true, I would interpret this as indicating
    that INDP (which carried both) is the one and only notification
    scheme that we should be mandating (which I do not advocate).

    Harry Lewis
    IBM Printing Systems

    "McDonald, Ira" <imcdonald@sharplabs.com>
    07/26/2000 08:46 AM

            To: Harry Lewis/Boulder/IBM@IBMUS, pmoore@peerless.com
            cc: ipp@pwg.org
            Subject: RE: IPP> notification methods

    Hi Harry,

    It is a serious mistake to limit email to human-readable.
    Otherwise I agree with your MUST for email below.

    The IETF does NOT like intranet-only solutions in IETF
    standards (they usually simply remove them). And a MUST
    solution for the Internet proper that can't convey the full
    'application/ipp' semantics is going to fail approval by
    the IETF.

    If we are developing an Internet standard then we should
    get on with it and abide by the IETF's rules and philosopy.

    Cheers,
    - Ira McDonald, consulting architect at Xerox and Sharp
      High North Inc

    -----Original Message-----
    From: harryl@us.ibm.com [mailto:harryl@us.ibm.com]
    Sent: Tuesday, July 25, 2000 10:01 PM
    To: pmoore@peerless.com
    Cc: ipp@pwg.org
    Subject: Re: IPP> notification methods

    I feel a more accurate way of looking at it is:

    1. If a device is configured to provide event notification across the
    Internet it MUST support mailto
    2. If a device is configured to provide event notification in the context
    of an Intranet it SHOULD support INDP

    We could live with the proposal to bind human/mail vs. machine/indp.
    However, this ignores the fact that INDP also handles human readable.

    Harry Lewis
    IBM Printing Systems

    pmoore@peerless.com
    Sent by: owner-ipp@pwg.org
    07/20/2000 09:31 AM

            To: ipp@pwg.org
            cc:
            Subject: IPP> notification methods

    Following the SF meeting I would like to formally propose the following.

    1. If a device wants to expose human readable events then it MUST support
    the
    mailto method

    2. If a device wants to expose machine readable events then it MUST
    support the
    INDP method

    But we do not UNCONDITIONALLY require either.

    (Now dons flame-proof clothing and awaits flaming)



    This archive was generated by hypermail 2b29 : Thu Jul 27 2000 - 16:00:54 EDT