Re: [apps-discuss] Spam reporting over IMAP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]