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