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

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

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

McDonald, Ira imcdonald at sharplabs.com
Tue Aug 15 21:51:59 EDT 2000


Hi,

Jay in his note below and many of the readers on
this list keep confusing and conflating 'real-time'
and 'machine-readable'.  There is NO relationship.

A client could want 'human-readable' status messages
in near 'real-time' (and SNMP print clients get
them every day today from private MIBs).

A client could want store and forward 'machine-readable'
notifications - invoking a reader that's generic
across ALL client-side browsers, email readers, etc.
on a given client operating system, similar to
to Adobe Acrobat Reader - because that client COULD
NOT get the near 'real-time' notification via INDP
due to corporate security policies.

Carl Kugler made the excellent point (adroitly ignored
by others in replying) that typical corporate security
policies completely prohibit HTTP Server side code
in any system that doesn't meet the corporate definition
of 'bastion host'.  Let me be clear - in such an
environment (the most common situation in mid-sized
and large corporations worldwide) it is impossible
for INDP to operate at all.  And 'mailto:' is the
sole RECOMMENDED alternative according to IPP folks.
Of course, they could use Job Mon traps via SNMP...

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

-----Original Message-----
From: Jay Martin [mailto:jkm at underscore.com]
Sent: Tuesday, August 15, 2000 11:58 AM
To: Herriot, Robert
Cc: IETF-IPP
Subject: Re: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -
The IPP Notification I-Ds will now go the IESG)


Bob,

> From: pmoore at peerless.com [mailto:pmoore at 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



More information about the Ipp mailing list