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 22:32:28 EDT 2000


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



More information about the Ipp mailing list