Hi Jay,
Compelling argument - the IPP Client is prohibited
by corporate policy from using INDP at all - that
IPP Client is either going to use the only other
RECOMMENDED notification delivery method for IPP
(SMTP via POP3/IMAP4 clients) and get 'machine-readable'
or be entirely out of luck - no usable notifications
at all for client software applications.
Bob's latest proposal is much simpler than past ones.
The 'machine-readable' format is FIXED at the
appropriate 'application/ipp' MIME type.
The 'multipart/report' format is much more appropriate
than the generic 'multipart/alternative' or
'multipart/related'.
Why are we shooting ourselves in the foot and precluding
clients incapable of using INDP from receiving full-function
IPP notifications?
Cheers,
- Ira McDonald
-----Original Message-----
From: Jay Martin [mailto:jkm at underscore.com]
Sent: Tuesday, August 15, 2000 7:19 PM
To: McDonald, Ira
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)
Ira,
> 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.
Perhaps that is how you see it. Technically speaking, you're
absolutely right. Technically, that is.
But, aside from Tom's observation about localization,
what compelling scenarios exist that require machine-readable
data other than those real-time things?
For many of us, "machine-readable" and "real-time" are
virtually conflated for all intents and purposes, aside
from the localization issue, of course.
You've proposed this scenario:
> 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.
Sounds like you're saying that real-time notifications
are the primary requirement driving the need for machine-readable
embeddings in email. Or am I misinterpreting this?
> 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'.
I don't believe that anyone was adroitly ignoring anything.
Too bad you interpreted the others' responses this way.
But let's get back to the question at hand: What are the
compelling reasons for having machine-readable (binary)
data embedded in email such that the simple text case won't
suffice?
...jay