[apps-discuss] FW: Spam reporting over IMAP

[Zoltan Ordogh <[e-mail]>]

Hi all,
I would like to address the issues that involve SM, Alessandro and John first.

I understand the confusion has risen because my name is listed as an author on draft-ordogh-spam-reporting-using-imap-kleansed-00.
I would like to make it clear that while draft-ordogh-spam-reporting-using-imap-kleansed-00 bears my name and I am listed as the author of this, I was not involved - nor consulted - on its development. I am of course happy to work with anyone who wishes to progress either draft as long as the work gets done in IETF. As I said before, if there is no interest to keep the work in IETF, while not desirable, it is perfectly fine; the work will happen in OMA EVVM.

I noticed that a declaration has been made on draft-ordogh-spam-reporting-using-imap-kleansed-00. This simple fact should answer SM's question.

Alessandro said he emailed Sarah and got no response. I asked Sarah and she told me she have not received any emails from Alessandro. The only thing I can add here is that RIM has very strict spam filters in place. The sender or the recipient will not know what happened to an email. If you do not get a response within a reasonable timeframe, please email the person again (with a different subject and body, to ensure that there's absolutely nothing in the mail that might trigger a spam filter). BTW, since I am bound by RIM's policies as Sarah, this holds true for my emails as well.

Speaking of IT policies.
Regarding John's concern about the disclaimer in the email message. It is an IT policy in RIM, there is nothing I can do about it as it is beyond my control. Since the emails are sent to a public mailing list, all information in the email can be considered public - in which case I believe that disclaimer does not apply. If I accidently put some information into that email that was not meant to be public, I will have to follow up on it and you will know.
 
Next, I try to do my best to address John's other comments below (2 through 4).

> -----Original Message-----
> From: John C Klensin [mailto:[e-mail]]
> Sent: January 14, 2012 12:40 PM
> To: Alessandro Vesely; Zoltan Ordogh
> Cc: ietf; [e-mail]
> Subject: Re: [apps-discuss] Spam reporting over IMAP
> 
> 
> 
> --On Saturday, January 14, 2012 14:32 +0100 Alessandro Vesely <[e-mail]> 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.
> 
[ZÖr] I addressed this above.

> (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.
> 

[ZÖr] I think I understand your concern. The draft contains one possible solution - one that fulfills the requirements set and was 'good enough' for OMA. It is not a draft from OMA. It is an individual contribution; OMA merely endorses it because it fulfills the requirement they need. I am fairly confident that if IETF can find a more efficient solution than the one in my draft, one that fulfills the requirement OMA needs, then OMA will be more than happy to discard my draft - even as a whole if need be - and go with the more efficient solution instead. The only concern I would expect OMA to raise in this case is the schedule (the availability of a fairly stable draft). I said already that I am happy to work with either document. I can also say that while I would not be particularly happy about discarding my draft considering the amount of time I invested in writing it and doing the legwork in OMA, I would not make a big deal out of discarding it in favor of a more efficient solution that achieves the objectives set.
These statements, as a whole, should re-assure that it is not a simple handoff of change control. Rather, an initial draft (including its imperfections) to kick off the work in IETF - a work entirely owned by IETF, as laid out in RFC3975. It is unfortunate that there was no response to the liaison statement sent from OMA to IETF; these things could have been clarified long ago.

> (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).

[ZÖr] I am not asking anyone to discuss the merits of either draft; in fact, I left out all technical discussions - on purpose. What I would like to figure whether IETF is interested on working on this topic - which is the same thing that was asked in the liaison statement. I mean, I can work offline with Alessandro and come up with a nice, consolidated draft - but that would not solve anything because in the end, we would have to ask the same questions afterwards; a draft supported by only two participants won't make it into a standards-track RFC. Ergo, more support to work on this topic (not a specific draft) would be needed. And, this is exactly what I am trying to figure out.
 
> 
> 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.

[ZÖr] From my perspective, these administrative issues have been addressed.

> 
> (4) The core of my previous comments was a technical concern, not an 
> administrative one.

[ZÖr] Again, I would like to leave technical discussions out, for now at least, especially because the draft in question may change substantially (maybe even thrown out) once the work starts.
 
> 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.
> 

[ZÖr] That is my understanding as well. After Lemonade concluded its work, there were rumors about IMAP5 - which, I understand, would have removed the unused things from the specifications, consolidated must-haves into the base spec, and tidied up the loose ends a bit. Unfortunately it did not happen, so we have to work with what we have - and however undesirable the situation is. Sooner or later, IETF will have to face this problem and deal with this issue, irrespective of any newly proposed extensions. If you ask me, the sooner it happens, the better. The problem has been identified already, which is always a good sign because it indicates that people know exactly what needs to be done. The only thing I am unsure of is: "What's keeping IETF from taking an action?". Standards evolve and soon, it will have been 10 years since IMAP4 was released. But, I believe that this discussion is more or less irrelevant to the original topic in question; this is not why I am knocking on the IETF door. OMA has decided to use IMAP4 already.

> 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.

[ZÖr] I cannot possibly comment on what gets picked up, what does not get picked up (or why) in individual client or server implementations, or, in various services. All I can say is that there is a hole, OMA is trying to fill it in and one possible solution has been created - and now I am trying to find out whether there's interest in working on this topic.

> 
> 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

[ZÖr] There is nothing I can add here that I have not said already. I have received a good deal of comments offline. I plan on addressing those, uploading a revision, checking in with Alessandro and addressing the rest of the comments later either as a new draft of an update.
Comments, new draft, comments, new drafts. Isn't it already a "work being done" in IETF driven by interest of individuals? Feels like normal IETF procedure to me. Just a thought.


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.