IMAP Access to IETF Email List Archives
draft-sparks-genarea-imaparch-08

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

(Barry Leiba; former steering group member) Yes

Yes ( for -07)
No email
send info

(Jari Arkko; former steering group member) Yes

Yes ( for -07)
No email
send info

(Pete Resnick; former steering group member) (was Discuss) Yes

Yes ()
No email
send info

(Spencer Dawkins; former steering group member) Yes

Yes ( for -07)
No email
send info

(Ted Lemon; former steering group member) Yes

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

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Benoît Claise; former steering group member) No Objection

No Objection (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?

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Martin Stiemerling; former steering group member) No Objection

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

(Richard Barnes; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Sean Turner; former steering group member) (was Discuss) No Objection

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

(Stephen Farrell; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Stewart Bryant; former steering group member) (was Discuss) No Objection

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