From: Bruce Lilly (blilly@erols.com)
Date: Mon Feb 10 2003 - 16:39:26 CST
Charles Lindsey wrote:
> In <3E3EDF25.3010501@Sonietta.blilly.com> Bruce Lilly <blilly@erols.com> writes:
>
>
>>Charles Lindsey wrote:
>>
>>>In <3E32A979.5080904@erols.com> Bruce Lilly <blilly@erols.com> writes:
>>>
>>>
>>>
>>>>Charles Lindsey wrote:
>>>
>>>
>>>>>In <3E2EB579.5080200@erols.com> Bruce Lilly <blilly@erols.com> writes:
>
>
>>>>>>3. There is no backwards compatibility ...
>>>
>>>If there is a feature in some existing protocol which becomes illegal in
>>>the new version, then that is a breech of "backwards compatibility".
>
>
>>Sorry, no -- you have that wrong.
>
>
>>>If there is a feature in some new protocol that will not work with
>>>implementations written for the old protocol, then that is a breech of
>>>"forwards compatibility".
>
>
>>Nope, wrong again.
>
>
>>>It seems you want to define these terms the other way around. Does anyone
>>>else here agree with your view? The weight of evidence is surely against
>>>you.
>
>
>>Don't take my word for it. Dave Crocker has clearly and unambiguously
>>explained to you what backwards compatibility does and does not
>>mean to the IETF, which is what counts....
>
>
>>>Just to check, I grepped through my small collection of online RFCs, and
>>>found usage of "backwards compatibility" in my sense in RFCs 1945, 2060 and
>>>2156. I found only one (RFC 2646) that seemed to use it your way, so the
>>>majority is against you. You are. however, welcome to produce further
>>>examples.
>
>
> I have quoted you three examples from IETF Standars-track documents that
> use the term "backwards compatibility" as I have defined it. And yet you
> claim that is not what it means to the IETF, and quote Dave Crocker in
> support of your view.
No, you have not quoted examples, you have listed RFC numbers. You are
wrong about RFC 2156; here's a quote:
" There are three places where an order is specified:
1. The text encoding (std-or-address) of MTS.ORAddress as used
in the local-part of an RFC 822 address. An order is needed
for those components which may have multiple values
(Organizational Unit, and Domain Defined Attributes). When
generating an 822.std-or-address, components of a given type
shall be in hierarchical order with the most significant
component on the RHS (right hand side or domain part). If
there is an Organization Attribute, it shall be to the right
of any Organizational Unit attributes. These requirements
are for the following reasons:
- Alignment to the hierarchy of other components in RFC
822 addresses (thus, Organizational Units will appear
in the same order, whether encoded on the RHS or LHS).
- Backwards compatibility with RFC 987/1026.
"
That is, as Dave has painstakingly pointed out to you, content
generated by a new implementation is compatible with the existing
installed base which was developed in compliance with earlier
standards. I haven't checked 1945 or 2060; I assume you're also
wrong about them unless and until you do provide a quote.
You're right about RFC 2646. And there are also RFCs 939, 1138, 1148,
1327, 1349, 1494, 1554, 1812, 1911, 1995, 1996, 2077, 2157, 2311, 2396,
2421, 2423, 2425, 2440, 2616, 2633, 2652, 2831, 2985, 3183, 3195, 3261.
and 3454, all of which use backwards compatibility in the same sense
as Dave has explained.
No matter; the real issue is what "backwards compatibility" means in
terms of the Usefor WG charter, and it's clear that that means the same
thing as Dave has described. It's also the same sense in which the term
has previously been used on tthe usenet-format list, e.g. last August.
Lame attempts to redefine the term at this late date in order to try
to wriggle out of the requirement in the charter to pay particular
attention to backwards compatibility simply won't fly.
>>Now, if you want to propose such
>>an incompatible format as part of a separate, parallel implementation,
>>that's another matter. That may well suffer the same fate as the
>>incompatible multimedia mail implementations mentioned by Dave Crocker.
>>Perhaps not. But existing protocols, software installations, etc. could
>>either continue to support RFC 1036 as is or adopt the hypothetical
>>new format or both, where practical.
>
>
> Yes, that is exactly what we are proposing. I am glad that you understand
> at last.
No, that is not what the Usefor draft is proposing; "a separate, parallel
implementation" is inconsistent with "obsoleting RFC 1036". It's also
incompatible with the WG charter.
>>Indeed we did. And what I actually said is "The draft provides no
>>means of moderation of extended newsgroups which is both acceptable
>>to moderators and compatible with the existing installed base of
>>RFC 1036-compliant UAs and gateways.", and that remains the case.
>>Encapsulation is unacceptable to moderators, and either passing
>>raw utf-8 or attempting to second-guess the UA in a gateway is
>>incompatible with the installed base (for that matter, encapsulation
>>is also incompatible with the existing installed base)..
>
> Yawn! The draft does not require, or even allow, raw UTF-8 to be passed to
> moderators. If you think it does, then please put up or shut up.
The draft permits a UA to generate raw utf-8. That is then passed to
an injection agent, which determines that one or more newsgroups are
moderated. Existing injection agents do not transform raw-utf-8,
and no existing or future injection agent can transform any untagged
8-bit content without charset and language information. If you still
don't understand that the UA must only generate compatible (i.e.
MIME 2047/2231) content because the existing infrastructure,
including injection agents and gateways, can't properly handle raw
untagged 8-bit content, then you may as well take a long walk on a
short pier.