IMAP Access to IETF Email List Archives
RFC 7017

Note: This ballot was opened for revision 07 and is now closed.

(Jari Arkko) Yes

(Spencer Dawkins) Yes

Barry Leiba Yes

(Ted Lemon) Yes

Comment (2013-06-27 for -07)
No email
send info
In section 2:
      -  The system must not require credentials for accessing lists
         with open archives.  (However, it is acceptable for a user to
         access such archives while providing credentials.)

I think this isn't quite right—it's really _necessary_ for a user to be able to access the archive either with a registered password or with either an anonymous login, or anonymous access.

How about this:

   - The system must allow access to open archives with or without
      providing credentials.

The rest of the text then nicely addresses how to not provide credentials. :)

I agree with Pete's suggestion to use quotas rather than requiring the administrator to make user-specific decisions.

In general, I strongly support this effort, and intend to use it extensively once it becomes available.   Thank you for working on it.

(Pete Resnick) (was Discuss) Yes

(Richard Barnes) No Objection

(Stewart Bryant) (was Discuss) No Objection

Comment (2013-06-25 for -07)
No email
send info
I remain nervous given the consequences of an error by the server operators, but since the apps folks tell me it's OK I will not block the draft.

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-06-24 for -07)
No email
send info
Robert,


- Excuse my ignorance regarding the annotation (not time to research this now)
      The interface should allow users that have provided credentials to
      each have their own read/unread marks for messages.  Allowing
      other annotation is desirable.  The implementation should consider
      taking advantage of the IMAP extensions for ANNOTATE [RFC5257] and
      METADATA [RFC5464].

Is this annotation on a per-user basis?
I guess so when I see:
      The interface must not allow users to modify the underlying
      message or metadata other than the read/unread marks and
      annotations described above. 

-
   Discussion of this memo should take place on the ietf@ietf.org
   mailing list.

do you still need this sentence?
Or is this sentence about the solution design, referring to "and it is intended 
as input to a later activity for the design and development of such a service." from the charter?

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

(Martin Stiemerling) No Objection

Comment (2013-06-26 for -07)
No email
send info
I have one question:
Is getting wrong or falsified copies out of this a threat?
I.e., if somebody is getting a full copy of a list, modifies the copy and uploads to some other server claiming that this is an authoritative copy?

Somebody could insert "not so nice" emails in this copy and start a campaign.

(Sean Turner) (was Discuss) No Objection

Comment (2013-06-21 for -07)
No email
send info
I'd love to support certs on this but as Robert points out this draft uses the authentication mechanism supported by the datatracker.  When the datatracker supports certs ... then we get certs with this.