Charles Lindsey wrote:
In <3E3EDF25(_dot_)3010501(_at_)Sonietta(_dot_)blilly(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
Charles Lindsey wrote:
In <3E32A979(_dot_)5080904(_at_)erols(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
Charles Lindsey wrote:
In <3E2EB579(_dot_)5080200(_at_)erols(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)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.