Use of SRV Records for Locating Email Submission/Access Services
draft-daboo-srv-email-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the No Objection position for Sean Turner |
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the No Objection position for Robert Sparks |
2010-06-17
|
05 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2010-06-16
|
05 | (System) | IANA Action state changed to No IC from In Progress |
2010-06-16
|
05 | (System) | IANA Action state changed to In Progress |
2010-06-16
|
05 | Amy Vezza | IESG state changed to Approved-announcement sent |
2010-06-16
|
05 | Amy Vezza | IESG has approved the document |
2010-06-16
|
05 | Amy Vezza | Closed "Approve" ballot |
2010-06-16
|
05 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss by David Harrington |
2010-06-16
|
05 | David Harrington | [Ballot comment] in section 6, "transport layer security" is a MUST; is this TLS, and if so, then should there be a reference to the … [Ballot comment] in section 6, "transport layer security" is a MUST; is this TLS, and if so, then should there be a reference to the TLS standard? or is any transport layer security mechanism good enough to meet the MUST? |
2010-06-16
|
05 | David Harrington | [Ballot discuss] |
2010-05-12
|
05 | (System) | New version available: draft-daboo-srv-email-05.txt |
2010-05-07
|
05 | (System) | Removed from agenda for telechat - 2010-05-06 |
2010-05-06
|
05 | Cindy Morgan | State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Cindy Morgan |
2010-05-06
|
05 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to Discuss from No Objection by David Harrington |
2010-05-06
|
05 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss by David Harrington |
2010-05-06
|
05 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2010-05-06
|
05 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss by Sean Turner |
2010-05-06
|
05 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo |
2010-05-06
|
05 | Stewart Bryant | [Ballot comment] There seems to be no definition of SRV in the draft, nor is it immediately apparent in the draft which reference to look … [Ballot comment] There seems to be no definition of SRV in the draft, nor is it immediately apparent in the draft which reference to look up to find the definition. |
2010-05-06
|
05 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant |
2010-05-05
|
05 | Sean Turner | [Ballot discuss] #1) Sec 5: The XMPP WG came up with the following text (thank you Peter and Simon) that, after being tweaked, needs to … [Ballot discuss] #1) Sec 5: The XMPP WG came up with the following text (thank you Peter and Simon) that, after being tweaked, needs to be added as a new 2nd paragraph: Implementations of TLS typically support multiple versions of the Transport Layer Security protocol as well as the older Secure Sockets Layer (SSL) protocol. Because of known security vulnerabilities, MUAs and MSAs MUST NOT request, offer, or use SSL 2.0. See Appendix E.2 of [TLS] for further details. |
2010-05-05
|
05 | Sean Turner | [Ballot discuss] #1) Sec 5: The XMPP WG came up with the following text (thank you Peter and Simon) that, after being tweaked, needs to … [Ballot discuss] #1) Sec 5: The XMPP WG came up with the following text (thank you Peter and Simon) that, after being tweaked, needs to be added as a new 2nd paragraph: Implementations of TLS typically support multiple versions of the Transport Layer Security protocol as well as the older Secure Sockets Layer (SSL) protocol. Because of known security vulnerabilities, MUAs and MSAs MUST NOT request, offer, or use SSL 2.0. See Appendix E.2 of [TLS] for further details. |
2010-05-05
|
05 | Robert Sparks | [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss by Robert Sparks |
2010-05-05
|
05 | David Harrington | [Ballot discuss] in section 6, "transport layer security" is a MUST; is this TLS, and if so, then should there be a reference to the … [Ballot discuss] in section 6, "transport layer security" is a MUST; is this TLS, and if so, then should there be a reference to the TLS standard? or is any transport layer security mechanism good enough to meet the MUST? |
2010-05-05
|
05 | Sean Turner | [Ballot discuss] #1) Sec 5: The XMPP WG came up with the following text (thank you Peter and Simon) that, after being tweaked, needs to … [Ballot discuss] #1) Sec 5: The XMPP WG came up with the following text (thank you Peter and Simon) that, after being tweaked, needs to be added as a new 2nd paragraph: Implementations of TLS typically support multiple versions of the Transport Layer Security protocol as well as the older Secure Sockets Layer (SSL) protocol. Because of known security vulnerabilities, MUAs and MSAs MUST NOT request, offer, or use SSL 2.0. See Appendix E.2 of [TLS] for further details. |
2010-05-05
|
05 | Sean Turner | [Ballot discuss] #1) Sec 5: The XMPP WG came up with the following text (thank you Peter and Simon) that, after being tweaked, that needs … [Ballot discuss] #1) Sec 5: The XMPP WG came up with the following text (thank you Peter and Simon) that, after being tweaked, that needs to be added as a new 2nd paragraph: Implementations of TLS typically support multiple versions of the Transport Layer Security protocol as well as the older Secure Sockets Layer (SSL) protocol. Because of known security vulnerabilities, MUAs and MSAs MUST NOT request, offer, or use SSL 2.0. See Appendix E.2 of [TLS] for further details. |
2010-05-05
|
05 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded by Sean Turner |
2010-05-05
|
05 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2010-05-05
|
05 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2010-05-05
|
05 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
2010-05-04
|
05 | Robert Sparks | [Ballot discuss] 1) Mixing priority values from SRV records for different services (to inform a service choice) seems unusual and dangerous. Is there precedent? … [Ballot discuss] 1) Mixing priority values from SRV records for different services (to inform a service choice) seems unusual and dangerous. Is there precedent? Is it the intent that a client supporting both POP3 and IMAP receiving this set of records: _imap._tcp SRV 1 2 143 huey.example.com _pop3._tcp SRV 1 3 110 dewey.example.com _imap._tcp SRV 1 5 143 louie.example.com would connect using POP3 30% of the time and IMAP the other 70%? Or did you intend for the client to pick a particular service (arbitrarily if the priorities are equal), and perform the load-leveling over weights per 2782 only within that service? The document should be clear on that point. 2) Something like a NAPTR based approach for advertising which services are preferred in combination with SRV seems a better tool. I'm told the group discussed this and explicitly chose not to go down that path at this time. Could that discussion be reflected in this document? Has the group considered making a transition to a NAPTR based solution in the future (the choice in question 1 above would have an impact, for instance). 3) The last paragraph of section 4 has a client cache all the results of the SRV resolution process until a subsequent connection attempt fails. This takes a great deal of the control SRV is intended to give operators away, making it harder to manage new connection load. Why is this lookup not done per connection, or the cache discarded when the chosen record's TTL expires? If an operator had the following configuration preferring IMAP: _imap._tcp SRV 1 1 143 imap.example.com _pop3._tcp SRV 10 1 110 pop3.example.com and imap.example.com was down long enough for a significant part of the population to attempt to reconnect, then that set of clients will be stuck on pop3 after the imap service comes back up until the pop3 service fails - if the provider really wants to move traffic back, his only recourse is to force the pop3 service to fail. (Or have I misread what that section was trying to say?) 4) The reference in "MUAs SHOULD use the TLS Server Name Indication [RFC5246]" seems off (since 5246 doesn't talk about that extension). Should this reference 4366-bis instead? |
2010-05-04
|
05 | Robert Sparks | [Ballot Position Update] New position, Discuss, has been recorded by Robert Sparks |
2010-05-03
|
05 | Peter Saint-Andre | [Ballot Position Update] New position, Yes, has been recorded by Peter Saint-Andre |
2010-05-03
|
05 | Peter Saint-Andre | [Ballot comment] In Section 3.4, I suggest changing "lower priority value" to "smaller priority value" so that implementers are not confused by the fact that … [Ballot comment] In Section 3.4, I suggest changing "lower priority value" to "smaller priority value" so that implementers are not confused by the fact that the "preferred" service has a "lower" priority. (In RFC 2782 this is called the "lowest-numbered priority".) |
2010-05-03
|
05 | David Harrington | [Ballot discuss] 1) in section 7, should the service label values defined in section 3 be registered in the iana-ports registry (being defined in the … [Ballot discuss] 1) in section 7, should the service label values defined in section 3 be registered in the iana-ports registry (being defined in the ietf-tsvwg-iana-ports draft), and/or the service-names registry? 2) in section 6, "transport layer security" is a MUST; is this TLS, and if so, then should there be a reference to the TLS standard? or is any transport layer security mechanism good enough to meet the MUST? |
2010-05-03
|
05 | David Harrington | [Ballot discuss] 1) in section 7, should the service label values defined in section 3 be registered in the iana-ports registry and/or the service-names registry? … [Ballot discuss] 1) in section 7, should the service label values defined in section 3 be registered in the iana-ports registry and/or the service-names registry? 2) in section 6, "transport layer security" is a MUST; is this TLS, and if so, then should there be a reference to the TLS standard? or is any transport layer security mechanism good enough to meet the MUST? |
2010-05-03
|
05 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to Discuss from No Objection by David Harrington |
2010-05-03
|
05 | David Harrington | [Ballot Position Update] New position, No Objection, has been recorded by David Harrington |
2010-04-23
|
05 | Alexey Melnikov | State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Alexey Melnikov |
2010-04-23
|
05 | Alexey Melnikov | Placed on agenda for telechat - 2010-05-06 by Alexey Melnikov |
2010-03-25
|
05 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2010-03-25
|
05 | Alexey Melnikov | Ballot has been issued by Alexey Melnikov |
2010-03-25
|
05 | Alexey Melnikov | Created "Approve" ballot |
2010-03-23
|
05 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-03-23
|
04 | (System) | New version available: draft-daboo-srv-email-04.txt |
2010-03-21
|
05 | Alexey Melnikov | (1.a) Who is the Document Shepherd for this document? Ned Freed Has the Document Shepherd personally reviewed this version of … (1.a) Who is the Document Shepherd for this document? Ned Freed Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes and yes. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? This document is not the product of a working group, however, notices regarding it have been sent to the ietf-smtp mailing list and substantial review has taken place there and elsewhere. Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? Since the document in question defines SRV records, review by DNS experts would be appropriate. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? No. For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? No. If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. (1.e) How solid is the WG consensus behind this document? This document is not the product of a working group. Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There appears to be a consensus behind the document on the ietf-smtp list. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? No. If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? == You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See http://trustee.ietf.org/license-info/) == Outdated reference: A later version (-03) exists of draft-saintandre-tls-server-id-check-02 ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246) (1.h) Has the document split its references into normative and informative? Yes. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? There is a normative reference to draft-saintandre-tls-server-id-check-02. If such normative references exist, what is the strategy for their completion? It is expected that the id check draft will be published as an RFC before this document is. Are there normative references that are downward references, as described in [RFC3967]? No. If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? Yes. If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? The document defines a number of SRV record service labels. At present there is no registration for such labels. Are the IANA registries clearly identified? n/a If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? n/a Does it suggest a reasonable name for the new registry? n/a See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? n/a (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This specification defines new SRV service types for the message submission, IMAP and POP3 services, to enable simple auto- configuration of MUAs. The priority field of the SRV record can also be used to indicate a preference for one message store access protocol over another. Working Group Summary This document was reviewed on the ietf-smtp mailing list but is not the product of a working group. Document Quality The documents have been extensively reviewed by people with expertise in email systems. |
2010-03-21
|
05 | Alexey Melnikov | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for Writeup::AD Followup by Alexey Melnikov |
2010-03-13
|
05 | Alexey Melnikov | State Changes to Waiting for Writeup::AD Followup from Waiting for Writeup::External Party by Alexey Melnikov |
2010-03-13
|
05 | Alexey Melnikov | saintandre-tls-server-id-check got updated, so this document should be updated to resolve issues related to TLS server identity verification and how this interacts with use of … saintandre-tls-server-id-check got updated, so this document should be updated to resolve issues related to TLS server identity verification and how this interacts with use of DNS SRV. |
2010-02-11
|
05 | Alexey Melnikov | State Changes to Waiting for Writeup::External Party from Waiting for Writeup::AD Followup by Alexey Melnikov |
2010-02-11
|
05 | Alexey Melnikov | Extra AD comments: This document is now waiting for saintandre-tls-server-id-check to be finished. The new section 3.4 needs to be clear if it applies to … Extra AD comments: This document is now waiting for saintandre-tls-server-id-check to be finished. The new section 3.4 needs to be clear if it applies to "secure" variants (imaps/pop3s), or when both "imap" and "imaps" are advertised. |
2010-02-05
|
05 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-02-05
|
03 | (System) | New version available: draft-daboo-srv-email-03.txt |
2009-09-17
|
05 | Alexey Melnikov | State Changes to Waiting for Writeup::Revised ID Needed from Waiting for AD Go-Ahead by Alexey Melnikov |
2009-09-17
|
05 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2009-09-10
|
05 | Sam Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Chris Lonvick. |
2009-09-08
|
05 | Amanda Baber | IANA comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2009-08-22
|
05 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2009-08-22
|
05 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2009-08-20
|
05 | Amy Vezza | Last call sent |
2009-08-20
|
05 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2009-08-20
|
05 | Alexey Melnikov | State Changes to Last Call Requested from AD Evaluation::AD Followup by Alexey Melnikov |
2009-08-20
|
05 | Alexey Melnikov | Last Call was requested by Alexey Melnikov |
2009-08-20
|
05 | (System) | Ballot writeup text was added |
2009-08-20
|
05 | (System) | Last call text was added |
2009-08-20
|
05 | (System) | Ballot approval text was added |
2009-08-20
|
05 | Alexey Melnikov | State Change Notice email list have been change to cyrus@daboo.name, draft-daboo-srv-email@tools.ietf.org, ned.freed@mrochek.com, chris.newman@sun.com from cyrus@daboo.name, draft-daboo-srv-email@tools.ietf.org |
2009-08-20
|
05 | Alexey Melnikov | [Note]: 'Ned Freed has agreed to shepherd the document' added by Alexey Melnikov |
2009-08-19
|
05 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-08-19
|
02 | (System) | New version available: draft-daboo-srv-email-02.txt |
2009-08-16
|
05 | Alexey Melnikov | State Changes to AD Evaluation::Revised ID Needed from Publication Requested::Revised ID Needed by Alexey Melnikov |
2009-08-04
|
05 | Alexey Melnikov | State Changes to Publication Requested::Revised ID Needed from Publication Requested by Alexey Melnikov |
2009-07-29
|
05 | Alexey Melnikov | State Changes to Publication Requested from AD is watching by Alexey Melnikov |
2009-07-08
|
05 | Alexey Melnikov | Draft Added by Alexey Melnikov in state AD is watching |
2009-07-08
|
01 | (System) | New version available: draft-daboo-srv-email-01.txt |
2009-05-22
|
00 | (System) | New version available: draft-daboo-srv-email-00.txt |