Mixing human readable content with the machine readable content and then
delivering that via e-mail is clearly POSSIBLE but not desirable. Why would I
want the machine actionable information to arrive on a client via mail? Besides
the issue of latency of e-mail, I would now have to find ways for my client
notification receipient program to work with ALL the mail programs (Notes,
Netscape, Outlook, Eudora, etc.) and to separate normal e-mail from notification
e-mail. YUCK! At Lexmark, all SMTP received mail is "gatewayed" to Lotus Notes
and would therefore be lost to the print notification receipient application.
We need a clean connection between the printer and the notification receipient
application and this isn't it.
**********************************************
* Don Wright don at 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 at interlock.lexmark.com on 07/28/2000 11:40:22 AM
To: Don_Wright/Lex/Lexmark at LEXMARK,
imcdonald%sharplabs.com at interlock.lexmark.com
cc: imcdonald%sharplabs.com at interlock.lexmark.com,
pmoore%peerless.com at interlock.lexmark.com,
ipp%pwg.org at interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark)
Subject: RE: IPP> notification methods [XHTML 1.0 in 'mailto:']
Hi Don,
On the contrary, XHTML (and plain HTML) can contain
'non-display' elements - we could easily say that
the string representation (consistent with LDAP
and SLP 'printer:' schemas) of all of the IPP
machine readable notification content attributes
were always place (for example) at the top of the
XHTML document (after the preamble) as 'non-display'
elements.
XHTML can get us BOTH a machine-readable and machine-
parseable representation and also a gracefully
transforming human-readable representation and
is HARMLESS to all existing deployed email systems
because the 'machine-readable' content is entirely
specified in plaintext.
Cheers,
- Ira McDonald
-----Original Message-----
From: don at lexmark.com [mailto:don at lexmark.com]
Sent: Thursday, July 27, 2000 8:12 AM
To: imcdonald at sharplabs.com
Cc: imcdonald at sharplabs.com; pmoore at peerless.com; ipp at pwg.org
Subject: 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 at 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 at interlock.lexmark.com on 07/26/2000 08:27:24 PM
To: imcdonald%sharplabs.com at interlock.lexmark.com,
pmoore%peerless.com at interlock.lexmark.com
cc: ipp%pwg.org at 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 at sharplabs.com]
Sent: Wednesday, July 26, 2000 4:27 PM
To: 'pmoore at peerless.com'; McDonald, Ira
Cc: 'ipp at 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 at peerless.com [mailto:pmoore at 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 at sharplabs.com> on 07/26/2000 09:45:14 AM
To: "'harryl at us.ibm.com'" <harryl at us.ibm.com>, "McDonald, Ira"
<imcdonald at sharplabs.com>
cc: ipp at pwg.org, pmoore at 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 at us.ibm.com [mailto:harryl at us.ibm.com]
Sent: Wednesday, July 26, 2000 8:07 AM
To: McDonald, Ira
Cc: ipp at pwg.org; pmoore at 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 at sharplabs.com>
07/26/2000 08:46 AM
To: Harry Lewis/Boulder/IBM at IBMUS, pmoore at peerless.com
cc: ipp at 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 at us.ibm.com [mailto:harryl at us.ibm.com]
Sent: Tuesday, July 25, 2000 10:01 PM
To: pmoore at peerless.com
Cc: ipp at 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 at peerless.com
Sent by: owner-ipp at pwg.org
07/20/2000 09:31 AM
To: ipp at 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)