IMAP QUOTA Extension
draft-ietf-extra-quota-10
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2022-04-04
|
10 | (System) | IANA registries were updated to include RFC9208 |
|
2022-03-31
|
10 | (System) | Received changes through RFC Editor sync (created alias RFC 9208, changed abstract to 'This document defines a QUOTA extension of the Internet Message Access … Received changes through RFC Editor sync (created alias RFC 9208, changed abstract to 'This document defines a QUOTA extension of the Internet Message Access Protocol (IMAP) (see RFCs 3501 and 9051) that permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. This document obsoletes RFC 2087 but attempts to remain backwards compatible whenever possible.', changed pages to 19, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2022-03-31, changed IESG state to RFC Published, created obsoletes relation between draft-ietf-extra-quota and RFC 2087) |
|
2022-03-31
|
10 | (System) | RFC published |
|
2022-03-23
|
10 | (System) | RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9208">AUTH48-DONE</a> from AUTH48 |
|
2022-02-24
|
10 | (System) | RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9208">AUTH48</a> |
|
2022-01-19
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from IANA |
|
2021-12-20
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2021-12-20
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
|
2021-12-20
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2021-12-17
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2021-12-17
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2021-12-14
|
10 | (System) | RFC Editor state changed to IANA from RFC-EDITOR |
|
2021-12-14
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
|
2021-12-09
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2021-12-06
|
10 | (System) | RFC Editor state changed to EDIT |
|
2021-12-06
|
10 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
|
2021-12-06
|
10 | (System) | Announcement was received by RFC Editor |
|
2021-12-06
|
10 | (System) | IANA Action state changed to In Progress |
|
2021-12-06
|
10 | Amy Vezza | Downref to RFC 5257 approved by Last Call for draft-ietf-extra-quota-10 |
|
2021-12-06
|
10 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
|
2021-12-06
|
10 | Amy Vezza | IESG has approved the document |
|
2021-12-06
|
10 | Amy Vezza | Closed "Approve" ballot |
|
2021-12-06
|
10 | Amy Vezza | Ballot approval text was generated |
|
2021-12-03
|
10 | (System) | Removed all action holders (IESG state changed) |
|
2021-12-03
|
10 | Murray Kucherawy | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
|
2021-11-18
|
10 | (System) | Changed action holders to Murray Kucherawy (IESG state changed) |
|
2021-11-18
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2021-11-18
|
10 | Alexey Melnikov | New version available: draft-ietf-extra-quota-10.txt |
|
2021-11-18
|
10 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2021-11-18
|
10 | Alexey Melnikov | Uploaded new revision |
|
2021-11-09
|
09 | Murray Kucherawy | Discussion of vendor prefixes with the WG is pending. |
|
2021-11-09
|
09 | (System) | Changed action holders to Alexey Melnikov, Murray Kucherawy (IESG state changed) |
|
2021-11-09
|
09 | Murray Kucherawy | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
|
2021-10-22
|
09 | (System) | Changed action holders to Murray Kucherawy (IESG state changed) |
|
2021-10-22
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2021-10-22
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
|
2021-10-22
|
09 | Alexey Melnikov | New version available: draft-ietf-extra-quota-09.txt |
|
2021-10-22
|
09 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2021-10-22
|
09 | Alexey Melnikov | Uploaded new revision |
|
2021-10-21
|
08 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss point! The COMMENT section from my ballot on the -07 is preserved unchanged below for convenience, even … [Ballot comment] Thank you for addressing my Discuss point! The COMMENT section from my ballot on the -07 is preserved unchanged below for convenience, even though some parts of it are resolved by the -08. Section 2 This document also reserves all other capabilities starting with "QUOTA=" prefix for future IETF stream standard track, informational or experimental extensions to this document. If we're allowing all three of those that doesn't leave much else. It might be simpler to just say "IETF stream extensions to this document". Section 3.1.1 The resource name is an atom, as defined in IMAP4rev1 [RFC3501]. These MUST be registered with IANA. Implementation specific resources begin with "V-" . Are V- prefixes going to work out any better here than X- prefixes did for header fields (viz BCP 178)? Also, it's a little surprising that the "should be followed by a domain name under vendor's control" guidance appears only as a comment within the ABNF and not here as well. Section 4.1.1 The client can try using any of the resource types returned in CAPABILITY response (i.e. all capability items with "QUOTA=RES-" This is the section about GETQUOTA, which only takes a quota root argument, not a particular resource type(s). Does it really make sense to talk about "using any of the resource types" here? (nit: if it does, we haven't really covered what a client might do that would qualify as "using" the resource types; is it worth putting in an "(e.g., for SETQUOTA") or something like that?) Section 4.1.3 The SETQUOTA command takes the name of a mailbox quota root and a list of resource limits. The resource limits for the named quota root are changed to be the specified limits. Any previous resource limits for the named quota root are discarded. That sounds like "any other quotas set on that quota root for resources not explicitly listed, are removed", which might be worth a specific note. Section 4.2.2 Example: S: * QUOTAROOT INBOX "" S: * QUOTAROOT comp.mail.mime I wonder if it's worth some commentary about there being no adminstrative resources associated with the comp.mail.mime quota root. I also saw that we used the "" quota root in previous examples, but do not have any commentary about whether it is distinct from an absent quota root. Maybe that's a natural part of IMAP and I've just forgotten about it, but if not, it might also be worth calling out. Section 4.3.1 currently selected mailbox. (The WG chose not to address this deficiency due to syntactic limitations of IMAP response codes and because such events are likely to be rare.) This form of the While I'm happy to see the WG's decision to not act documented, I'm not sure how much precedent we have for documenting it as a parenthetical sentence with the phrase "The WG chose". Unfortunately I don't have any alternative phrasings to suggest, so this may just be a non-actionable remark... Section 6 I'm not sure I understand how "only one of 'r' and 'none'" is required for GETQUOTAROOT -- doesn't that just degenerate to "no rights are required"? Section 7 The <resource-names> construction appears to be defined but not used. Where are <status-att-deleted> and <status-att-deleted-storage> previously defined that we need to use the "=/" style definition? I don't see them in RFC 9051. Section 8 Is it worth saying anything about the potential for deleterious results when a user runs SETQUOTA for a quota root shared with other users? Relatedly, giving quota information to a user that shares a quota root with other users (which AFAICT is something that must be known out of band) gives an information channel about how effective a denial of service via the shared resource is, though this is admittedly unlikely to be of great practical impact. Section 12 When compared with RFC 2087, this document defines two more commonly used resource type, adds optional OVERQUOTA response code and defines two extra STATUS data items ("DELETED" and "DELETED-STORAGE") that must be implemented. [...] Can you clarify the "must be implemented"? I thought they were mandatory only if QUOTA=RES-MESSAGE and QUOTA=RES-STORAGE were advertised, respectively. NITS Abstract The QUOTA extension of the Internet Message Access Protocol (RFC 3501/RFC 9051) permits administrative limits on resource usage The reference is a bit ambiguous as to whether it means (core) IMAP or the QUOTA extension. Maybe something like "this document defines a QUOTA extension to [IMAP, RFC 3051/9051]" that permits ..."? Section 1 are not part of the protocol. Lines without any of these prefixes are continuations of the previous line, and no line break is present in the protocol unless specifically mentioned. My understanding is that there is a "line break" in the protocol at the end of each "C:" or "S:" line, which is a little hard to get to from the phrasing here. Section 2 Any server compliant with this document MUST also return at least one capability starting with "QUOTA=RES-" prefix, as described in Section 3.1. Does the "also" refer to "in addition to the QUOTA capability"? Section 3.2 A server implementation of this memo SHOULD advise the client of such inherent limits, by generating QUOTA (Section 4.2.1) responses and SHOULD advise the client of which resources are limitable for a particular quota root. [...] I think this wants another comma before "and SHOULD advise", since "by generating QUOTA responses" is a parenthetical expression expounding on "SHOULD advise the client of such inherent limits". Section 4.1.4 DELETED status data item requests the server to return the number of messages with \Deleted flag set. DELETED status data item is only "The DELETED" (both instances). Also "The DELETED-STORAGE" in the following paragraph, twice. Section 4.3.1 Do we feel a desire to avoid request/response tag reuse for examples within the same section? Section 5.1 When the server supports this resource type, it MUST also support DELETED-STORAGE status data item. "the DELETED-STORAGE" (and similarly for §5.2). |
|
2021-10-21
|
08 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
|
2021-10-21
|
08 | (System) | Changed action holders to Alexey Melnikov, Murray Kucherawy (IESG state changed) |
|
2021-10-21
|
08 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
|
2021-10-21
|
08 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss |
|
2021-10-21
|
08 | Michelle Cotton | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
|
2021-10-21
|
08 | John Scudder | [Ballot comment] Thanks for the very readable document. One minor note, while “The WG chose not to address this…” is both helpful while reviewing, and … [Ballot comment] Thanks for the very readable document. One minor note, while “The WG chose not to address this…” is both helpful while reviewing, and completely clear to any IETFer with a meeting or two under their belt, it might not be clear to an outsider. Please at minimum expand “WG”, and also consider writing it in a way that doesn’t assume knowledge of our process, as in the more stilted and less-specific :-( “it was chosen not to address this…” |
|
2021-10-21
|
08 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
|
2021-10-21
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
|
2021-10-21
|
08 | Alexey Melnikov | New version available: draft-ietf-extra-quota-08.txt |
|
2021-10-21
|
08 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2021-10-21
|
08 | Alexey Melnikov | Uploaded new revision |
|
2021-10-21
|
07 | Zaheduzzaman Sarker | [Ballot comment] I marked the discrepancies about the QUOTA response in section 4.2.1 and section 4.1.3. Ben already have a Discuss on it. I am … [Ballot comment] I marked the discrepancies about the QUOTA response in section 4.2.1 and section 4.1.3. Ben already have a Discuss on it. I am supporting that discuss. Moreover, I think section 6 needs to explain the Operations\Rights for GETQUOTAROOT. There are two * for r and Non. Not sure why and how to interpret them. |
|
2021-10-21
|
07 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
|
2021-10-21
|
07 | Francesca Palombini | [Ballot comment] Thank you for the work on this document. Many thanks to Todd Herr for the ART ART review: https://mailarchive.ietf.org/arch/msg/art/i8noFdN8QVycrT1bAgOktoAGsaM/ Francesca |
|
2021-10-21
|
07 | Francesca Palombini | Ballot comment text updated for Francesca Palombini |
|
2021-10-20
|
07 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
|
2021-10-20
|
07 | Warren Kumari | [Ballot comment] I support Benjamin Kaduk's Discuss, but other than that don't have anything useful to add.... |
|
2021-10-20
|
07 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
|
2021-10-20
|
07 | Francesca Palombini | [Ballot comment] Thank you for the work on this document. Many thanks to Todd Herr for the ART ART review. I only have two comments; … [Ballot comment] Thank you for the work on this document. Many thanks to Todd Herr for the ART ART review. I only have two comments; although not worth a DISCUSS (because in the examples), I'd really appreciate an answer. Francesca 1. ----- S: S0001 OK Rounded quota FP: This is not defined - should it be "OK setquota completed" ? 2. ----- C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE) S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8) FP: I think the above should be MESSAGE rather than MESSAGES. |
|
2021-10-20
|
07 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
|
2021-10-20
|
07 | Robert Wilton | [Ballot comment] Hi, One minor nit, the diagram in example 3 in 4.3.1 is indented beyond example 2. I presume that this is just a … [Ballot comment] Hi, One minor nit, the diagram in example 3 in 4.3.1 is indented beyond example 2. I presume that this is just a nit, and is not intended to infer any meaning. Rob |
|
2021-10-20
|
07 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
|
2021-10-18
|
07 | Benjamin Kaduk | [Ballot discuss] The description of the QUOTA response in §4.2.1 only says that the response can occur due to GETQUOTA and GETQUOTAROOT, but it is … [Ballot discuss] The description of the QUOTA response in §4.2.1 only says that the response can occur due to GETQUOTA and GETQUOTAROOT, but it is also described as a possible result of SETQUOTA, in §4.1.3. |
|
2021-10-18
|
07 | Benjamin Kaduk | [Ballot comment] Section 2 This document also reserves all other capabilities starting with "QUOTA=" prefix for future IETF stream standard track, informational … [Ballot comment] Section 2 This document also reserves all other capabilities starting with "QUOTA=" prefix for future IETF stream standard track, informational or experimental extensions to this document. If we're allowing all three of those that doesn't leave much else. It might be simpler to just say "IETF stream extensions to this document". Section 3.1.1 The resource name is an atom, as defined in IMAP4rev1 [RFC3501]. These MUST be registered with IANA. Implementation specific resources begin with "V-" . Are V- prefixes going to work out any better here than X- prefixes did for header fields (viz BCP 178)? Also, it's a little surprising that the "should be followed by a domain name under vendor's control" guidance appears only as a comment within the ABNF and not here as well. Section 4.1.1 The client can try using any of the resource types returned in CAPABILITY response (i.e. all capability items with "QUOTA=RES-" This is the section about GETQUOTA, which only takes a quota root argument, not a particular resource type(s). Does it really make sense to talk about "using any of the resource types" here? (nit: if it does, we haven't really covered what a client might do that would qualify as "using" the resource types; is it worth putting in an "(e.g., for SETQUOTA") or something like that?) Section 4.1.3 The SETQUOTA command takes the name of a mailbox quota root and a list of resource limits. The resource limits for the named quota root are changed to be the specified limits. Any previous resource limits for the named quota root are discarded. That sounds like "any other quotas set on that quota root for resources not explicitly listed, are removed", which might be worth a specific note. Section 4.2.2 Example: S: * QUOTAROOT INBOX "" S: * QUOTAROOT comp.mail.mime I wonder if it's worth some commentary about there being no adminstrative resources associated with the comp.mail.mime quota root. I also saw that we used the "" quota root in previous examples, but do not have any commentary about whether it is distinct from an absent quota root. Maybe that's a natural part of IMAP and I've just forgotten about it, but if not, it might also be worth calling out. Section 4.3.1 currently selected mailbox. (The WG chose not to address this deficiency due to syntactic limitations of IMAP response codes and because such events are likely to be rare.) This form of the While I'm happy to see the WG's decision to not act documented, I'm not sure how much precedent we have for documenting it as a parenthetical sentence with the phrase "The WG chose". Unfortunately I don't have any alternative phrasings to suggest, so this may just be a non-actionable remark... Section 6 I'm not sure I understand how "only one of 'r' and 'none'" is required for GETQUOTAROOT -- doesn't that just degenerate to "no rights are required"? Section 7 The <resource-names> construction appears to be defined but not used. Where are <status-att-deleted> and <status-att-deleted-storage> previously defined that we need to use the "=/" style definition? I don't see them in RFC 9051. Section 8 Is it worth saying anything about the potential for deleterious results when a user runs SETQUOTA for a quota root shared with other users? Relatedly, giving quota information to a user that shares a quota root with other users (which AFAICT is something that must be known out of band) gives an information channel about how effective a denial of service via the shared resource is, though this is admittedly unlikely to be of great practical impact. Section 12 When compared with RFC 2087, this document defines two more commonly used resource type, adds optional OVERQUOTA response code and defines two extra STATUS data items ("DELETED" and "DELETED-STORAGE") that must be implemented. [...] Can you clarify the "must be implemented"? I thought they were mandatory only if QUOTA=RES-MESSAGE and QUOTA=RES-STORAGE were advertised, respectively. NITS Abstract The QUOTA extension of the Internet Message Access Protocol (RFC 3501/RFC 9051) permits administrative limits on resource usage The reference is a bit ambiguous as to whether it means (core) IMAP or the QUOTA extension. Maybe something like "this document defines a QUOTA extension to [IMAP, RFC 3051/9051]" that permits ..."? Section 1 are not part of the protocol. Lines without any of these prefixes are continuations of the previous line, and no line break is present in the protocol unless specifically mentioned. My understanding is that there is a "line break" in the protocol at the end of each "C:" or "S:" line, which is a little hard to get to from the phrasing here. Section 2 Any server compliant with this document MUST also return at least one capability starting with "QUOTA=RES-" prefix, as described in Section 3.1. Does the "also" refer to "in addition to the QUOTA capability"? Section 3.2 A server implementation of this memo SHOULD advise the client of such inherent limits, by generating QUOTA (Section 4.2.1) responses and SHOULD advise the client of which resources are limitable for a particular quota root. [...] I think this wants another comma before "and SHOULD advise", since "by generating QUOTA responses" is a parenthetical expression expounding on "SHOULD advise the client of such inherent limits". Section 4.1.4 DELETED status data item requests the server to return the number of messages with \Deleted flag set. DELETED status data item is only "The DELETED" (both instances). Also "The DELETED-STORAGE" in the following paragraph, twice. Section 4.3.1 Do we feel a desire to avoid request/response tag reuse for examples within the same section? Section 5.1 When the server supports this resource type, it MUST also support DELETED-STORAGE status data item. "the DELETED-STORAGE" (and similarly for §5.2). |
|
2021-10-18
|
07 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
|
2021-10-18
|
07 | Roman Danyliw | [Ballot comment] ** Section 8. Should the prohibition on revealing quota information be a bit stronger? OLD In particular, no quota information should be … [Ballot comment] ** Section 8. Should the prohibition on revealing quota information be a bit stronger? OLD In particular, no quota information should be disclosed to anonymous users. NEW In particular, quota information SHOULD be disclosed only to authenticated and authorized users ** Section 8. Should it be noted that computing remaining resources might incur a load on the server. Implementers might want to rate limit or return less precise computations when under higher load? ** Typos Section 3.2. Typo. s/arbitary/arbitrary/ Section 3.2. Typo. s/dependant/dependant/ |
|
2021-10-18
|
07 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
|
2021-10-15
|
07 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
|
2021-10-15
|
07 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-extra-quota-07. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-extra-quota-07. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the Internet Message Access Protocol (IMAP) Capabilities Registry located at: https://www.iana.org/assignments/imap-capabilities/ the following actions will be taken: IANA will update the current reference of the QUOTA extension to point to [ RFC-to-be ]. IANA will add a single new registration to the Capabilities Registry as follows: Capability Name: QUOTASET Reference: [ RFC-to-be ] IANA will add a note to the registry indicating that the prefix "QUOTA=RES-" is reserved with a reference to [ RFC-to-be; Section 9.2 ]. IANA will also add a note to the registry which reserves all other capabilities starting with "QUOTA=" prefix for future IETF stream standard track, informational or experimental extensions to [ RFC-to-be ]. Second, a new registry is to be created called IMAP Quota Resource Types. The new registry will be located on the Internet Message Access Protocol (IMAP) Capabilities Registry page located at: https://www.iana.org/assignments/imap-capabilities/ The registration policy for the new registry is Specification Required as defined in RFC8126. There are initial registrations in the new registry as follows: Name of the quota resource type: STORAGE Author: Alexey Melnikov <alexey.melnikov@isode.com> Change Controller: IESG <iesg@ietf.org> Description: The physical space estimate, in units of 1024 octets, of the mailboxes governed by the quota root. Extra required IMAP commands/responses: DELETED-STORAGE STATUS request data item and response data item Extra optional IMAP commands/responses: N/A Reference: [ RFC-to-be; Section 5.1] Name of the quota resource type: MESSAGE Author: Alexey Melnikov <alexey.melnikov@isode.com> Change Controller: IESG <iesg@ietf.org> Description: The number of messages stored within the mailboxes governed by the quota root. Extra required IMAP commands/responses: DELETED STATUS request data item and response data item Extra optional IMAP commands/responses: N/A Reference: Section [ RFC-to-be; Section 5.2] Name of the quota resource type: MAILBOX Author: Alexey Melnikov <alexey.melnikov@isode.com> Change Controller: IESG <iesg@ietf.org> Description: The number of mailboxes governed by the quota root. Extra required IMAP commands/responses: N/A Extra optional IMAP commands/responses: N/A Reference: [ RFC-to-be; Section 5.3 ] Name of the quota resource type: ANNOTATION-STORAGE Author: Alexey Melnikov <alexey.melnikov@isode.com> Change Controller: IESG <iesg@ietf.org> Description: The maximum size of all annotations [RFC5257], in units of 1024 octets, associated with all messages in the mailboxes governed by the quota root. Extra required IMAP commands/responses: N/A Extra optional IMAP commands/responses: N/A Reference: Section [ RFC-to-be; Section 5.4 ] The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Lead IANA Services Specialist |
|
2021-10-11
|
07 | Lars Eggert | |
|
2021-10-11
|
07 | Lars Eggert | [Ballot comment] Section 13.1. , paragraph 1, comment: > [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for > … [Ballot comment] Section 13.1. , paragraph 1, comment: > [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for > Syntax Specifications: ABNF", RFC 5234, January 2008, > <ftp://ftp.isi.edu/in-notes/rfc5234.txt>. Please use https://www.rfc-editor.org/info/rfc5234 as the URL. ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 2. , paragraph 8, nit: - dependant, it was impossible for a client implementation to determine - ^ + dependent, it was impossible for a client implementation to determine + ^ Section 3.2. , paragraph 4, nit: - calculate usage, or apply quotas, on arbitary mailboxes or mailbox + calculate usage, or apply quotas, on arbitrary mailboxes or mailbox + + Section 3.2. , paragraph 5, nit: - Not all resources may be limitable or calculatable for all quota - -- + Not all resources may be limitable or calculable for all quota Section 3.2. , paragraph 5, nit: - quota limit in an implementation dependant way, if the granularity of - ^ ^ + quota limit in an implementation-dependent way, if the granularity of + ^ ^ Reference [RFC3501] to RFC3501, which was obsoleted by RFC9051 (this may be on purpose). Found non-HTTP URLs in the document: * ftp://ftp.isi.edu/in-notes/rfc5234.txt These URLs in the document can probably be converted to HTTPS: * http://www.iana.org/assignments/imap4-capabilities |
|
2021-10-11
|
07 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded for Lars Eggert |
|
2021-10-11
|
07 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Please find below COMMENT points, which are mere nits. Special thanks to Bron Gondwana … [Ballot comment] Thank you for the work put into this document. Please find below COMMENT points, which are mere nits. Special thanks to Bron Gondwana for his shepherd's write-up about the WG consensus. I hope that this helps to improve the document, Regards, -éric -- Section 3.2 -- For a reader non familiar with the domain, this section is quite cryptic until the "implementation notes". Giving some early examples would be a plus. -- Section 4.1.1 -- In the same vein as the comment above, a non-familiar reader (like myself :-O ) will wonder how the client knows to check the quota for "!partition/sda4". Suggest to explain the example a little more. |
|
2021-10-11
|
07 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
|
2021-10-07
|
07 | Cindy Morgan | Placed on agenda for telechat - 2021-10-21 |
|
2021-10-07
|
07 | Murray Kucherawy | [Ballot comment] Thank you to Todd Herr for his ARTART review. |
|
2021-10-07
|
07 | Murray Kucherawy | Ballot comment text updated for Murray Kucherawy |
|
2021-10-07
|
07 | Murray Kucherawy | Ballot has been issued |
|
2021-10-07
|
07 | Murray Kucherawy | [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy |
|
2021-10-07
|
07 | Murray Kucherawy | Created "Approve" ballot |
|
2021-10-07
|
07 | Murray Kucherawy | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
|
2021-10-07
|
07 | Murray Kucherawy | Ballot writeup was changed |
|
2021-10-07
|
07 | Murray Kucherawy | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
|
2021-10-04
|
07 | Amy Vezza | The following Last Call announcement was sent out (ends 2021-10-18):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: brong@fastmailteam.com, draft-ietf-extra-quota@ietf.org, … The following Last Call announcement was sent out (ends 2021-10-18):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: brong@fastmailteam.com, draft-ietf-extra-quota@ietf.org, extra-chairs@ietf.org, extra@ietf.org, superuser@gmail.com Reply-To: last-call@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-extra-quota-07.txt> (IMAP QUOTA Extension) to Proposed Standard The IESG has received a request from the Email mailstore and eXtensions To Revise or Amend WG (extra) to consider the following document: - 'IMAP QUOTA Extension' <draft-ietf-extra-quota-07.txt> as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-10-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The QUOTA extension of the Internet Message Access Protocol (RFC 3501/RFC 9051) permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. This document obsoletes RFC 2087, but attempts to remain backwards compatible whenever possible. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-extra-quota/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5257: Internet Message Access Protocol - ANNOTATE Extension (Experimental - Internet Engineering Task Force (IETF)) |
|
2021-10-04
|
07 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
|
2021-10-04
|
07 | Amy Vezza | Last call announcement was generated |
|
2021-10-04
|
07 | Murray Kucherawy | Last call was requested |
|
2021-10-04
|
07 | (System) | Changed action holders to Murray Kucherawy (IESG state changed) |
|
2021-10-04
|
07 | Murray Kucherawy | IESG state changed to Last Call Requested from Waiting for AD Go-Ahead::AD Followup |
|
2021-09-24
|
07 | (System) | Removed all action holders (IESG state changed) |
|
2021-09-24
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2021-09-24
|
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
|
2021-09-24
|
07 | Alexey Melnikov | New version available: draft-ietf-extra-quota-07.txt |
|
2021-09-24
|
07 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2021-09-24
|
07 | Alexey Melnikov | Uploaded new revision |
|
2021-09-22
|
06 | Murray Kucherawy | Changed action holders to Alexey Melnikov |
|
2021-09-22
|
06 | (System) | Changed action holders to Alexey Melnikov, Murray Kucherawy (IESG state changed) |
|
2021-09-22
|
06 | Murray Kucherawy | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for Writeup |
|
2021-09-13
|
06 | Linda Dunbar | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Linda Dunbar. Sent review to list. |
|
2021-09-10
|
06 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
|
2021-09-10
|
06 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
|
2021-09-09
|
06 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
|
2021-09-09
|
06 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-extra-quota-06. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-extra-quota-06. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the Internet Message Access Protocol (IMAP) Capabilities Registry located at: https://www.iana.org/assignments/imap-capabilities/ the following actions will be taken: IANA will update the current reference of the QUOTA extension to point to [ RFC-to-be ]. IANA will add a single new registration to the Capabilities Registry as follows: Capability Name: QUOTASET Reference: [ RFC-to-be ] IANA will add a note to the registry indicating that the prefix "QUOTA=RES-" is reserved with a reference to [ RFC-to-be; Section 9.2 ]. IANA will also add a note to the registry which reserves all other capabilities starting with "QUOTA=" prefix for future IETF stream standard track, informational or experimental extensions to [ RFC-to-be ]. Second, a new registry is to be created called IMAP Quota Resource Types. IANA Question --> Where should this new registry be located? Should it be added to an existing registry page (for instance, the Internet Message Access Protocol (IMAP) Capabilities Registry located at: https://www.iana.org/assignments/imap-capabilities/? If it needs a new page, does it also need a new category at http://www.iana.org/protocols (and if so, should the page and the category have the same name)? The registration policy for the new registry is Specification Required as defined in RFC8126. There are initial registrations in the new registry as follows: Name of the quota resource type: STORAGE Author: Alexey Melnikov <alexey.melnikov@isode.com> Change Controller: IESG <iesg@ietf.org> Description: The physical space estimate, in units of 1024 octets, of the mailboxes governed by the quota root. Extra required IMAP commands/responses: DELETED-STORAGE STATUS request data item and response data item Extra optional IMAP commands/responses: N/A Reference: [ RFC-to-be; Section 5.1] Name of the quota resource type: MESSAGE Author: Alexey Melnikov <alexey.melnikov@isode.com> Change Controller: IESG <iesg@ietf.org> Description: The number of messages stored within the mailboxes governed by the quota root. Extra required IMAP commands/responses: DELETED STATUS request data item and response data item Extra optional IMAP commands/responses: N/A Reference: Section [ RFC-to-be; Section 5.2] Name of the quota resource type: MAILBOX Author: Alexey Melnikov <alexey.melnikov@isode.com> Change Controller: IESG <iesg@ietf.org> Description: The number of mailboxes governed by the quota root. Extra required IMAP commands/responses: N/A Extra optional IMAP commands/responses: N/A Reference: [ RFC-to-be; Section 5.3 ] Name of the quota resource type: ANNOTATION-STORAGE Author: Alexey Melnikov <alexey.melnikov@isode.com> Change Controller: IESG <iesg@ietf.org> Description: The maximum size of all annotations [RFC5257], in units of 1024 octets, associated with all messages in the mailboxes governed by the quota root. Extra required IMAP commands/responses: N/A Extra optional IMAP commands/responses: N/A Reference: Section [ RFC-to-be; Section 5.4 ] The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Lead IANA Services Specialist |
|
2021-09-06
|
06 | Shawn Emery | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Shawn Emery. Sent review to list. |
|
2021-09-03
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Linda Dunbar |
|
2021-09-03
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Linda Dunbar |
|
2021-09-02
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Shawn Emery |
|
2021-09-02
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Shawn Emery |
|
2021-08-31
|
06 | Todd Herr | Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Todd Herr. Sent review to list. |
|
2021-08-30
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Fred Baker |
|
2021-08-30
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Fred Baker |
|
2021-08-27
|
06 | Barry Leiba | Request for Last Call review by ARTART is assigned to Todd Herr |
|
2021-08-27
|
06 | Barry Leiba | Request for Last Call review by ARTART is assigned to Todd Herr |
|
2021-08-27
|
06 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
|
2021-08-27
|
06 | Cindy Morgan | The following Last Call announcement was sent out (ends 2021-09-10):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: brong@fastmailteam.com, draft-ietf-extra-quota@ietf.org, … The following Last Call announcement was sent out (ends 2021-09-10):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: brong@fastmailteam.com, draft-ietf-extra-quota@ietf.org, extra-chairs@ietf.org, extra@ietf.org, superuser@gmail.com Reply-To: last-call@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-extra-quota-06.txt> (IMAP QUOTA Extension) to Proposed Standard The IESG has received a request from the Email mailstore and eXtensions To Revise or Amend WG (extra) to consider the following document: - 'IMAP QUOTA Extension' <draft-ietf-extra-quota-06.txt> as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-09-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The QUOTA extension of the Internet Message Access Protocol (RFC 3501/RFC 9051) permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. This document obsoletes RFC 2087, but attempts to remain backwards compatible whenever possible. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-extra-quota/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5257: Internet Message Access Protocol - ANNOTATE Extension (Experimental - Internet Engineering Task Force (IETF)) |
|
2021-08-27
|
06 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
|
2021-08-27
|
06 | Murray Kucherawy | Last call was requested |
|
2021-08-27
|
06 | Murray Kucherawy | Ballot approval text was generated |
|
2021-08-27
|
06 | Murray Kucherawy | Ballot writeup was generated |
|
2021-08-27
|
06 | (System) | Changed action holders to Murray Kucherawy (IESG state changed) |
|
2021-08-27
|
06 | Murray Kucherawy | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
|
2021-08-27
|
06 | Murray Kucherawy | Last call announcement was generated |
|
2021-08-27
|
06 | (System) | Removed all action holders (IESG state changed) |
|
2021-08-27
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2021-08-27
|
06 | Alexey Melnikov | New version available: draft-ietf-extra-quota-06.txt |
|
2021-08-27
|
06 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2021-08-27
|
06 | Alexey Melnikov | Uploaded new revision |
|
2021-08-27
|
05 | Murray Kucherawy | Changed action holders to Alexey Melnikov |
|
2021-08-27
|
05 | (System) | Changed action holders to Alexey Melnikov, Murray Kucherawy (IESG state changed) |
|
2021-08-27
|
05 | Murray Kucherawy | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
|
2021-08-21
|
05 | (System) | Changed action holders to Murray Kucherawy (IESG state changed) |
|
2021-08-21
|
05 | Murray Kucherawy | IESG state changed to AD Evaluation from Publication Requested |
|
2021-08-19
|
05 | Bron Gondwana | Document Shepherd Write-Up for draft-ietf-extra-quota 1. This document is being requested as an Proposed Standard because it extends an existing Proposed Standard (RFC3501) … Document Shepherd Write-Up for draft-ietf-extra-quota 1. This document is being requested as an Proposed Standard because it extends an existing Proposed Standard (RFC3501) and obsoletes another Proposed Standard (RFC2087). The request type is indicated in the title page header as "Standards Track". 2. Technical Summary This spec extends IMAP with additional commands (GETQUOTA, GETQUOTAROOT, SETQUOTA) and new STATUS attributes (DELETED and DELETED-STORAGE), allowing clients to determine how much space is used by an IMAP account and how much additional space might be available. Working Group Summary There was no significant disagreement. The main questions were around whether particular features were worth including, and whether the syntax was reliably parseable for OVERQUOTA responses that included tags (they were eventually removed as being un-necessary and ambiguous). Document Quality This spec is quite easy to implement. Most IMAP servers are already basically compatible because they have implemented RFC2087. Personnel Document Shepherd - Bron Gondwana (EXTRA co-chair) Responsible Area Director - Murray Kucherawy 3. The Document Shepherd has read the document through in detail and has plans to implement it in the Cyrus IMAP server. 4. There are no concerns about reviews, this document has been well reviewed. 5. There is no review required for the document by other areas. 6. There are no concerns with this document that IESG should be aware of. 7. Yes, the author has been contacted and confirmed and confirmed that they have no disclosures. 8. There have been no IPR disclosures filed. 9. The WG consensus is solid. 10. There has been no discontent. 11. The ID nits tool complains about a non-RFC2606-compliant FQDN, but this is a false positive on a newsgroup name example. It also complains that the document date is February 2022, which also appears to be a tool bug, as that is the expiry date on the draft. 12. This document doesn't define anything which needs formal review outside the working group. 13. All references have been identified as either normative or informative. 14. All normative references are published standards. 15. There is a normative reference to an experimental RFC (RFC5257) however this specification was written in 2008 and is widely enough used that we should probably update it to a Proposed Standard as well. The only reference to that RFC is documenting an extension to allow quotas for those annotations as well. 16. This RFC obsoletes one other RFC, RFC2087. 17. The IANA considerations ask that the imap4-capabilities registry both have an entry updated, and have a prefix registered to restrict the use of that prefix to IETF consesensus documents. 18. There is a new registry requested for IMAP quota resource types. The initial contents of the registry are set out clearly in the document. The registration policy is "Specification Required". 19. The formal sections were validated with Chris Newman's ABNF validator tool. |
|
2021-08-19
|
05 | Bron Gondwana | Responsible AD changed to Murray Kucherawy |
|
2021-08-19
|
05 | Bron Gondwana | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
|
2021-08-19
|
05 | Bron Gondwana | IESG state changed to Publication Requested from I-D Exists |
|
2021-08-19
|
05 | Bron Gondwana | IESG process started in state Publication Requested |
|
2021-08-19
|
05 | Bron Gondwana | Tag Revised I-D Needed - Issue raised by WG cleared. |
|
2021-08-19
|
05 | Bron Gondwana | Document Shepherd Write-Up for draft-ietf-extra-quota 1. This document is being requested as an Proposed Standard because it extends an existing Proposed Standard (RFC3501) … Document Shepherd Write-Up for draft-ietf-extra-quota 1. This document is being requested as an Proposed Standard because it extends an existing Proposed Standard (RFC3501) and obsoletes another Proposed Standard (RFC2087). The request type is indicated in the title page header as "Standards Track". 2. Technical Summary This spec extends IMAP with additional commands (GETQUOTA, GETQUOTAROOT, SETQUOTA) and new STATUS attributes (DELETED and DELETED-STORAGE), allowing clients to determine how much space is used by an IMAP account and how much additional space might be available. Working Group Summary There was no significant disagreement. The main questions were around whether particular features were worth including, and whether the syntax was reliably parseable for OVERQUOTA responses that included tags (they were eventually removed as being un-necessary and ambiguous). Document Quality This spec is quite easy to implement. Most IMAP servers are already basically compatible because they have implemented RFC2087. Personnel Document Shepherd - Bron Gondwana (EXTRA co-chair) Responsible Area Director - Murray Kucherawy 3. The Document Shepherd has read the document through in detail and has plans to implement it in the Cyrus IMAP server. 4. There are no concerns about reviews, this document has been well reviewed. 5. There is no review required for the document by other areas. 6. There are no concerns with this document that IESG should be aware of. 7. Yes, the author has been contacted and confirmed and confirmed that they have no disclosures. 8. There have been no IPR disclosures filed. 9. The WG consensus is solid. 10. There has been no discontent. 11. The ID nits tool complains about a non-RFC2606-compliant FQDN, but this is a false positive on a newsgroup name example. It also complains that the document date is February 2022, which also appears to be a tool bug, as that is the expiry date on the draft. 12. This document doesn't define anything which needs formal review outside the working group. 13. All references have been identified as either normative or informative. 14. All normative references are published standards. 15. There is a normative reference to an experimental RFC (RFC5257) however this specification was written in 2008 and is widely enough used that we should probably update it to a Proposed Standard as well. The only reference to that RFC is documenting an extension to allow quotas for those annotations as well. 16. This RFC obsoletes one other RFC, RFC2087. 17. The IANA considerations ask that the imap4-capabilities registry both have an entry updated, and have a prefix registered to restrict the use of that prefix to IETF consesensus documents. 18. There is a new registry requested for IMAP quota resource types. The initial contents of the registry are set out clearly in the document. The registration policy is "Specification Required". 19. The formal sections were validated with Chris Newman's ABNF validator tool. |
|
2021-08-19
|
05 | Alexey Melnikov | New version available: draft-ietf-extra-quota-05.txt |
|
2021-08-19
|
05 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2021-08-19
|
05 | Alexey Melnikov | Uploaded new revision |
|
2021-03-01
|
04 | Bron Gondwana | Added to session: IETF-110: extra Fri-1530 |
|
2021-02-22
|
04 | Alexey Melnikov | New version available: draft-ietf-extra-quota-04.txt |
|
2021-02-22
|
04 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2021-02-22
|
04 | Alexey Melnikov | Uploaded new revision |
|
2020-12-03
|
03 | Bron Gondwana | Notification list changed to brong@fastmailteam.com because the document shepherd was set |
|
2020-12-03
|
03 | Bron Gondwana | Document shepherd changed to Bron Gondwana |
|
2020-11-18
|
03 | Bron Gondwana | As discussed at IETF109. |
|
2020-11-18
|
03 | Bron Gondwana | Tag Revised I-D Needed - Issue raised by WG set. |
|
2020-11-18
|
03 | Bron Gondwana | IETF WG state changed to In WG Last Call from WG Document |
|
2020-11-17
|
03 | Alexey Melnikov | New version available: draft-ietf-extra-quota-03.txt |
|
2020-11-17
|
03 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2020-11-17
|
03 | Alexey Melnikov | Uploaded new revision |
|
2020-07-01
|
02 | Alexey Melnikov | New version available: draft-ietf-extra-quota-02.txt |
|
2020-07-01
|
02 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2020-07-01
|
02 | Alexey Melnikov | Uploaded new revision |
|
2020-06-15
|
01 | Alexey Melnikov | New version available: draft-ietf-extra-quota-01.txt |
|
2020-06-15
|
01 | (System) | New version accepted (logged-in submitter: Alexey Melnikov) |
|
2020-06-15
|
01 | Alexey Melnikov | Uploaded new revision |
|
2019-12-19
|
00 | (System) | Document has expired |
|
2019-11-21
|
00 | Bron Gondwana | Changed consensus to Yes from Unknown |
|
2019-11-21
|
00 | Bron Gondwana | Intended Status changed to Proposed Standard from None |
|
2019-06-23
|
00 | Alexey Melnikov | This document now replaces draft-melnikov-extra-quota instead of None |
|
2019-06-17
|
00 | Alexey Melnikov | New version available: draft-ietf-extra-quota-00.txt |
|
2019-06-17
|
00 | (System) | WG -00 approved |
|
2019-06-17
|
00 | Alexey Melnikov | Set submitter to "Alexey Melnikov <alexey.melnikov@isode.com>", replaces to (none) and sent approval email to group chairs: extra-chairs@ietf.org |
|
2019-06-17
|
00 | Alexey Melnikov | Uploaded new revision |