--On Saturday, January 14, 2012 14:32 +0100 Alessandro Vesely <vesely@xxxxxxx> wrote: >... >> A bit later, a liaison statement was sent from OMA to IETF, >> seeking collaboration and a "home" for the draft; as >> required by RFC3975. > > I assume you're still talking about SREP. I read a reply by > John Klensin, whom I consider a sort of IETF guru, and it > didn't prospect a bright future for the draft. I posted a > "kleansed" version trying to address some of those concerns, > in an attempt to improve the chances that APPSAWG will adopt > it. Somewhat arbitrarily, I changed the IPR qualification of > the document too. In fact, I had the impression that the IPR > was that way because OMA SpamRep was being mentioned, albeit > not being specified, and also because that was one of the > points raised. > I hope my editing was correct, but your approval as author is > needed. >... Alessandro, Zoltan, Guru or not (some would certainly dispute that), this is strictly a personal comment and personal opinion. Just to clarify my view of this (other may have different opinions)... (1) I think SM's question, and anything else having to do with the IRP status of this document (or pair of documents) has to be completely clear. The IETF could certainly decide to process the document even if the technology were encumbered (has happened many times before), but uncertainty is pretty much a showstopper. Alessandro's concerns about distribution disclaimers on email messages that discuss the topic only reinforce my concern in this area. (2) Similarly, both of you, and RIM and OMA, need to understand that handing something like this off to IETF, especially for standards-track processing, is a handoff of change control. The IETF can modify (we hope improve) things as it likes, even after approval of the first version of the document as a Proposed Standard. Joint ownership/ change control arrangements are possible, but they are very hard and time-consuming to negotiate and perhaps, due to some bad experience, likely to get harder. (3) The leadership of AppAWG, and the ADs, will do as they think appropriate, but, if I were making the rules, no one would spend energy trying to sort out the differences between a pair of competing documents. I suggest that the two of you get together, offlist, and see if you can reach clear agreement on a single draft that supercedes both documents. That is a matter of courtesy to those of us you are asking to consider the work and is quite independent of the IPR concerns (although they do interact). All three of those issues are administrative, not technical. They should be easily solved. My personal preferences is that the AppsAWG, and the apps-discuss list, spend no more time on this until/unless they are resolved. YMMD, of course. (4) The core of my previous comments was a technical concern, not an administrative one. Even if one ignores the security concerns, the stability issues for normative references, and so on, many of us believe that the IMAP protocol has become far too complicated, with too many options and features. That complexity increases the requirements on IMAP servers that wish to support a wide range of clients and applications and on clients that wish to support a reasonable range of features but work with servers that may not support all of them. Whatever the advantages, too much code and too many code paths are not conducive to very high quality, bug-free, implementations. This proposal seems to me to take IMAP into a whole new area. I'm not questions whether or not that is possible because I'd be certain it would be, even without the assertiosn that there are implementations out there. I am questioning whether there is a strong enough case to be made that this belongs in IMAP to justify further clutter in the protocol and even lower odds of seeing high-quality clients. I observe that probably the best general-purpose --as distinct from, e.g., specialized for mobile devices-- IMAP client out there is now quite old, largely unmaintained, and has not picked up on any of the new features added in the last several years. Neither version of the document really addresses that issue. Some of the comments from the two of you about why it is hard and/or expensive to do it in other ways certainly have merit, but need, IMO, to be balanced off against other considerations including the above. That balance won't be easy to find especially since, as I am sure you both know, there is no community agreement about the degree to which it is appropriate to make normal, desired, email work worse in order to provide better facilities for spam-handling, especially spam-handling at or after the final delivery MTA. Bottom line: I think we should see a single draft that really addresses all of the technical issues, including the design tradeoffs and security topics, _and_ addresses the IPR/administrative one in a way with which we can all be comfortable before being asked to decide whether AppsAWG should take this up. If asked to make a decision without such a draft having been posted, I would vote "no". john _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf