IPP Mail Archive: RE: IPP>NOT mailto feature from IETF meeti

IPP Mail Archive: RE: IPP>NOT mailto feature from IETF meeti

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

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Tue Aug 15 2000 - 22:48:50 EDT

  • Next message: Jay Martin: "Re: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM - The IPP Notification I-Ds will now go the IESG)"

    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@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



    This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 23:02:24 EDT