On Wed, 2008-02-27 at 11:58 -0800, Dan Karp wrote: > > The proposed changes in the comments below create significiant > > incompatibilities with multiple interoperable client and server > > implementations that have been in production use and widely > > distributed worldwide for several years. > > > > The result of making any of these changes would be instability and > > inconsistency between implementations, creating an environment in > > which nobody can use these extensions because there is no reliable > > behavior. > > If there's a problem with the draft -- for instance, that the FROM sort > is useless from a client standpoint or that the CC sort will never be > used by a real-world client -- then it should be fixed before reaching > RFC status. If the resulting RFC is not protocol- or algorithm- > equivalent to revision 19 of the SORT draft, then this would not be the > first time that an extension's CAPABILITY string would have to change at > the time of publication. I don't see a point in breaking a lot of client and server implementations that implement the draft in its current form. The draft has stayed almost the same for at least 5 years (I implemented it then the first time). > I don't think that "But that doesn't match the behavior of a previous > version of the draft" is a useful argument at Last Call time. I think these changes should have been discussed long before reaching last call. The draft is over 10 years old already!
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf