IMAP Access to IETF Email List Archives
draft-sparks-genarea-imaparch-08
Yes
(Barry Leiba)
(Jari Arkko)
(Pete Resnick)
(Spencer Dawkins)
No Objection
(Adrian Farrel)
(Gonzalo Camarillo)
(Richard Barnes)
(Stephen Farrell)
Note: This ballot was opened for revision 07 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(for -07)
Unknown
Jari Arkko Former IESG member
Yes
Yes
(for -07)
Unknown
Pete Resnick Former IESG member
(was Discuss)
Yes
Yes
()
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(for -07)
Unknown
Ted Lemon Former IESG member
Yes
Yes
(2013-06-27 for -07)
Unknown
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 IESG member
No Objection
No Objection
(for -07)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2013-06-24 for -07)
Unknown
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 IESG member
No Objection
No Objection
(for -07)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(2013-06-26 for -07)
Unknown
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 IESG member
No Objection
No Objection
(for -07)
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2013-06-21 for -07)
Unknown
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 IESG member
No Objection
No Objection
(for -07)
Unknown
Stewart Bryant Former IESG member
(was Discuss)
No Objection
No Objection
(2013-06-25 for -07)
Unknown
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.