Simon, > I'm not convinced these protocols qualify for DS status. DS status > requires a lot, specifically that ALL features in the document have been > demonstrated interoperable, and that their normative references are DS. > I implemented IMAP and wrote > <http://josefsson.org/nnimap/buggy-imap-servers.html>, I'm pretty sure > others implementing other protocols have had similar experiences and > frustration. >
In the case of the base IMAP there are SO many implementations that I'm going to guess (not being fully conversant in IMAP) that the vast majority of the base specification is well covered. We are aware of some interoperability issues with Calendaring, and you're probably right on that one. My guess is that LDAP is closer to IMAP than Calendaring. But what you write is even true with HTTP, which *is* DS. There are lots of little nits with that protocol that the community has expressed in interest in seeing corrected. But let me turn it around. If ALL it takes are two or even three implementations to demonstrate interoperability, that really says nothing about maturity. Take for example SNMPv3. It was rushed through to full standard, and yet the deployment issues remainsubstantial, and are only now being addressed in ISMS. And SNMPv3 is a full standard. [I'm not really trying to pick on v3, but to make the point that what we have by way of markers in RFC 2026 isn't useful]. > Shouldn't we instead be eliminating it entirely? > > > I'm not sure about this. I used to think DS was useless, but it doesn't > seem actively harmful. I think the problem is that we don't have a > replacement for it today. If we can come up with a scheme to allow the > community to know which standards are mature and which are not, and that > scheme actually works, I think we could eliminate the DS way. But until > that happens, I'm not sure. > In the case of SNMPv3, I could argue that the premature declaration was actually harmful because it stalled development of workable solutions that integrated security on the device. I was specifically told that people wanted to let the standard bake in code before allowing for any sort of updates. Again, I am not saying that SNMPv3 is bad, but that it needed to continue to evolve in some areas, and was prevented from doing so by premature ossification. Now one could argue that this is not the general case with our process, but we have so few examples to pick from ;-( I like the idea that we are reviewing proposals that have been put before us in the past (Larry Masinter's was just mentioned), and I am hopeful that we can DEossify our own process ;-) Eliot _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
