From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Tue Feb 04 2003 - 06:26:32 CST
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.
>Reread what Dave wrote in <38167744153.20030107093025@brandenburg.com>:
>"
[snip long quote from Dave Crocker]
The word "backwards" did not occur once within that text. So it hardly
serves to prove your point.
What Dave was mostly talking about in that extract was what I call
_forwards_ compatibility. And yes, it has to be done with care, but if you
never do it at all, then you are stuck for the next 1000 years, like I
said.
>>>>>4. Compatibility (as exists under RFC 1036) would be broken with
>>>>>interoperating
>>>>> protocols including IMAP and SMTP.
>>
>> IMAP works with the existing news protocols. If, as a result of our draft,
>> the news protocols change, then a matching change in the IMAP protocol
>> would be in order.
>That would again break backwards compatibility, and so would almost
>certainly never be approved as such.
No, it would break forwards compatibility. If people used the new
feature, then it would appear garbled to people using the old software.
But it would not cause it to break (indeed, people are already used to
seeing such garbled headers in both news and mail, so it will not come as
any great surprise).
The question to be addressed is whether it is reasonable to break forward
compatibility in this case. The oppinion expressed by the WG is that, on
balance, it is, since the people who really want to read the new "garbled"
stuff can always obtain upgraded software and people who do not want to
read it will "just hit delete" as they do now.
> 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.
>>>>>6. The draft requires modification of non-trace header fields, which is
>>>>>incompatible
>>>>> with message signing. ...
>>
>> No, this situation cannot arise. See RFC 3156 which states:
>> "For this reason all data signed according to this protocol MUST be
>> constrained to 7 bits (8- bit data MUST be encoded using either
>> Quoted-Printable or Base64)."
>> So you could not have a UTF-8 header such as
>> Content-Disposition: attachment; filename = "זרו"
>> within the signed portion (so RFC 2231 encoding would be necessary in that
>> case).
>That is precisely why signed content must originate in a
>compatible format at the UA and be maintained so. It is
>pointless to try to sign something that is required to be
>modified (e.g. by a gateway to a moderator) in transit.
Good! I am glad we agree. I have already said that this particular matter
needs to be mentioned in our draft, so why are you still going on about
it?
>>>>>8. The draft provides no means of moderation ...
>>>>
>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.
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clw.cs.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5