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: Jay Martin (jkm@underscore.com)
Date: Tue Aug 15 2000 - 22:57:14 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)"

    Ira,

    > Therefore, the plaintext body of the simple 'mailto:'
    > notification CANNOT contain really useful localized
    > stuff unless the IPP Printer assumes a very significant
    > additional implementation burden (e.g, full POSIX
    > message catalogs with substitution parameters).

    Ummm...I think we're talking past each other here.
    I think we're in violent agreement.

    And yes, you're right. This whole argument is _VERY_ odd.

            ...jay

    "McDonald, Ira" wrote:
    >
    > Jay,
    >
    > This whole argument is _very_ odd.
    >
    > The IPP Client ALREADY has to do client-side
    > localization of ALL of the names of IPP attributes
    > and the keyword values for many IPP attributes.
    >
    > The IPP Printer PRESENTLY never has to do server-side
    > localization of any of those.
    >
    > Therefore, the plaintext body of the simple 'mailto:'
    > notification CANNOT contain really useful localized
    > stuff unless the IPP Printer assumes a very significant
    > additional implementation burden (e.g, full POSIX
    > message catalogs with substitution parameters).
    >
    > Cheers,
    > - Ira McDonald, consulting architect at Xerox and Sharp
    > High North Inc
    >
    > -----Original Message-----
    > From: Jay Martin [mailto:jkm@underscore.com]
    > Sent: Tuesday, August 15, 2000 6:22 PM
    > To: Hastings, Tom N
    > Cc: Herriot, Robert; IETF-IPP
    > Subject: Re: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -
    > The IPP Notification I-Ds will now go the IESG)
    >
    > > Does allowing the Notification Recipient [to] localize the messages make
    > it more
    > > desirable to require the Printer to send machine consumable upon client
    > > request (in addition to the text/plain)?
    >
    > Yes, but I'll bet big money that the COSTS substantially outweigh
    > the BENEFITS. Remember, you're talking some serious client-side
    > installations to make this work as you describe.
    >
    > I'm not saying that your analysis isn't correct, or that your
    > conclusions aren't interesting. (They are.) I just think that the
    > serious client-side software situation would drive the costs so
    > as to exceed the benefits.
    >
    > I'd like to hear what others thing along these lines.
    >
    > ...jay



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