Thanks for your succinct clarification (your note below). Your
previous note was VERY helpful for those PWG members (many) who
are also active in the IPP (Internet Print Protocol) Working
Group, where the advisability of labelling character set and language
(with tags as in RFC 1766) is receiving more attention in the
last six weeks.
Cheers,
- Ira McDonald (outside consultant at Xerox)
High North Inc
--------------------------- Keith's note ------------------------------
Return-Path: <moore@cs.utk.edu>
Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1)
id AA16864; Sat, 26 Jul 97 14:32:05 EDT
Received: from alpha.xerox.com by zombi (4.1/SMI-4.1)
id AA16240; Sat, 26 Jul 97 14:28:47 EDT
Received: from spot.cs.utk.edu ([128.169.92.189]) by alpha.xerox.com with SMTP id <51886(2)>; Sat, 26 Jul 1997 11:28:52 PDT
Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK)
id OAA19311; Sat, 26 Jul 1997 14:27:18 -0400 (EDT)
Message-Id: <199707261827.OAA19311@spot.cs.utk.edu>
X-Uri: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: imcdonal@eso.mc.xerox.com (Ira Mcdonald x10962)
Cc: Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu, pmp@pwg.org
Subject: Re: Clarification on earlier mail
In-Reply-To: Your message of "Sat, 26 Jul 1997 06:54:46 PDT."
<9707261354.AA16820@snorkel.eso.mc.xerox.com>
Date: Sat, 26 Jul 1997 11:27:12 PDT
Sender: moore@cs.utk.edu
Status: R
I'm sorry if my earlier note was confusing -- I was addressing
the general I18N issue rather than attempting to anaylze the
situation specifically for Printer MIB.
As you said, Printer MIB is not a new protocol.
If you've got significant backward compatibility issues --
e.g. if existing SMTP management stations (clients) won't
satisfactorily interoperate with new printers whose MIBs use
UTF-8 or some other form of IS 10646 -- then you would appear
to have adequate reason for not mandating UTF-8 or 10646,
and instead allowing a variety of charsets and labelling them.
Keith
p.s. I do want to clear up a common misconception. Changes in
the Draft Standard MIB would not retroactively label a number of
implementations non-conformant. Those implementations should
be claiming conformance to RFC 1759 (if they conform), not
to the new MIB.
The purpose of multiple standards maturity levels is to provide an
opportunity to fix things that were broken at earlier stages.
If the only changes needed are clarifications, that's wonderful,
but it's quite common for a Draft Standard specification to require
changes which prevent some existing implementations from claiming
conformance to the Draft Standard version. This should not be a
barrier to making such changes to the specification if there's a
good reason to do so.
On the other hand, interoperability with the installed base
is very important!