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:john-ietf(_at_)jck(_dot_)com]
Sent: January 14, 2012 12:40 PM
To: Alessandro Vesely; Zoltan Ordogh
Cc: ietf; apps-discuss(_at_)ietf(_dot_)org
Subject: Re: [apps-discuss] Spam reporting over IMAP
--On Saturday, January 14, 2012 14:32 +0100 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> 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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf