From: Bruce Lilly (blilly@erols.com)
Date: Thu Mar 06 2003 - 10:54:21 CST
Terje Bless wrote:
> I observe that a significant portion of the Netnews community have elected
> to reject RFC2047. I postulate, based on anecdotal evidence, that this is
> due to some real or percieved inadequacy of RFC2047. I further posit that
> since the years since its introduction and the changes made in at least one
> update to it has so far failed to persuade this portion of the community to
> adopt it, the likelyhood is very small that any further attempt to persuade
> them will be successfull.
>
>
> As best I can understand your position you feel that the proper response to
> this is to ignore them since they have brought this situation on
> themselves. Is my understanding correct?
No, in the first place, reasons for "rejection" in the distant past
are not necessarily relvant today. Nor am I proposing to "ignore them";
if there are valid and substantive issues with RFC 2047, let's hear them.
If, OTOH, the situation is "we decided umpteen years ago to go down
this road and refuse to reevaluate that decision now", then it may
well be best to ignore them.
> I happen to believe that it is inappropriate to allow IMAP's "adoption" of
> Netnews to constrain us too far [...]
The news article format (RFC 1036) is a subset of the general message
format (RFC 822 as extended and amended by the host requirements, MIME,
etc.). IMAP didn't "adopt" "Netnews"; IMAP (and SMTP, POP, etc.) handles
the full message format, including the subset that is "news".
> Given the choice of whom will be disadvantaged to
> achieve interoperability, I hesitate very little to place the burden at the
> feet of IMAP (you are of course free to disagree).
Retaining the compatibility with the general message format doesn't
disadvantage anybody other than those who have intentionally
disregarded that standard -- and the primary purpose of that standard
is to ensure interoperability.
>>Before utf-8 can become a blessed charset, the issue of RFC
>>2277-compliant language tagging needs to be addressed.
>
>
> I'm not entirely sure I agree with the necessity for that,
It's rather simple; RFC 2277 reguires that any protocol preserve language
information which a user may wish to indicate; the relevant language tags
are described in RFC 3066. The original charter of this WG was to produce
a standards-track RFC, which will have to comply with RFC 2277 (among
others). It of course remains to be seen what the revised charter will
contain, but it's probably safe to say that production of a standards-
track successor to RFC 1036 will be a part of it.
> The
> constructive thing for you, as an obvious expert on these matters, to do
> would be to suggest ways this can be achieved. I'm sure any help in fully
> exploring all the alternatives would be very much appreciated by everyone.
For a variety of reasons explained in some detail recently, the short
answer is "use RFC 2047". As I've said, anything that will work will
need to bear a marked similarity to RFC 2047 (delimiters, language tags,
etc.), and there's not much point in reinventing the wheel, especially as
there will be a learning curve associated with implementation, just as
there was in the case of MIME. That of course means that the utf-8 would
not be "raw" but would in fact be RFC 2047 tagged and encoded. I don't
consider myself a proponent of raw utf-8; any detailed work on a proposal
for compatible, BCP-compliant use of raw utf-8, including language-tagging,
will have to come from the proponents of raw utf-8.