Subject: Re: [apps-discuss] Spam reporting over IMAP

From: SM <[email-masked]>
Date: Sat, 14 Jan 2012 04:00:29 -0800

Hi Zoltan,
At 11:11 13-01-2012, Zoltan Ordogh wrote:
>Instead of responding to individual emails one by one, I try to 
>clarify some of the concerns at least in a single response.

The single response does not address the issue I raised ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04079.html ).

>PS. I am solely a technical contributor, so asking me IPR-related 
>questions will always be a dead end. Please direct those questions 
>directly to the appropriate contact person, which, in, this case is 
>Sarah Guichard. Thank you.

draft-ordogh-spam-reporting-using-imap-kleansed-00 lists Zoltan 
Ordogh, Research In Motion Limited, as the author of the 
Internet-Draft.  The document states that:

   "This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79."

Do you have any concerns about 
draft-ordogh-spam-reporting-using-imap-kleansed-00 in respect to BCP 
78 and BCP 79?

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 14 Jan 2012 14:32:26 +0100

Hi Zoltan,

On 13/Jan/12 20:11, Zoltan Ordogh wrote:
> 
> I would like to start with a story.

A rather similar story is summarized here:
http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs

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

> PS. I am solely a technical contributor,

So am I (but I signed no contract.)

> so asking me IPR-related questions will always be a dead end.

As a survival requirement, you have to be able to answer SM's
question, though.

> Please direct those questions directly to the appropriate contact
> person, which, in, this case is Sarah Guichard.

I sent my previous comment on this to Jon M. Jurgovan, cc Sarah
Guichard, but had no reply either.

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

The above boilerplate formally makes of no effect whatever else you
wrote in that message, according to Andrew's explanation:
http://www.ietf.org/mail-archive/web/ietf/current/msg67516.html

I usually group these issues to the same bin I use for IPRs, as I
guess many others on this list do.  Unfortunately, at times they
become relevant, which is why we have to deal with them.  See
"survival" above :-)

Specifically, if you need a written authorization of your employer in
order to contribute technical specifications to the IETF under IETF's
terms, please ask them to provide it.  I guess we need that paperwork.

Ciao
Ale

---

From: John C Klensin <[email-masked]>
Date: Sat, 14 Jan 2012 12:40:06 -0500

--On Saturday, January 14, 2012 14:32 +0100 Alessandro Vesely
<[email-masked]> 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

>...

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