Skip to main content

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