The 'mailto' URI Scheme
RFC 6068

[Ballot comment]
#1) Sec 5:  Don't you mean encrypted as opposed to encoded in the following sentence:

If the messages are not encoded, they can also be read at any of
those sites.

[Ballot discuss]
[Updated.  #2 was addressed by an RFC editor's note]

#1) Security Considerations: I'd like to add some words that suggest a user check that the URI that is resolved (or shows up in the To: line of the email message they're about to start typing) in fact matches the URI that is presented.  This check helps users avoid unknowingly sending email to an address that does not match the presented  address.

[Ballot comment]
#1) Sec 5:  Don't you mean encrypted as opposed to encoded in the following sentence:

If the messages are not encoded, they can also be read at any of
those sites.

[Ballot discuss]
[Updated.  #2 was addressed]

#1) Security Considerations: I'd like to add some words that suggest a user check that the URI that is resolved (or shows up in the To: line of the email message they're about to start typing) in fact matches the URI that is presented.  This check helps users avoid unknowingly sending email to an address that does not match the presented  address.

[Ballot comment]
#1) Sec 5:  Don't you mean encrypted as opposed to encoded in the following sentence:

If the messages are not encoded, they can also be read at any of
those sites.

[Ballot discuss]
#1) Security Considerations: I'd like to add some words that suggest a user check that the URI that is resolved (or shows up in the To: line of the email message they're about to start typing) in fact matches the URI that is presented.  This check helps users avoid unknowingly sending email to an address that does not match the presented  address.

#2) Security Considerations: At least one widely deployed mail app has had problems with the way mailto is associated with the email app.  I'd like to see some text add that addresses how to mitigate the risks associated with: http://www.us-cert.gov/cas/techalerts/TA04-070A.html.

[Ballot discuss]
#1) Security Considerations: I'd like to add some words that suggest a user check that the URI that is resolved (or shows up in the To: line of the email message they're about to start typing) in fact matches the URI that is presented.  This check helps users avoid unknowingly sending email to an address that does not match the presented  address.

#2) Security Considerations: At least one widely deployed mail app has had problems with the way mailto is associated with the email app.  I'd like to see some text add that addresses how to mitigate the risks associated with: http://www.us-cert.gov/cas/techalerts/TA04-070A.html.

[Ballot discuss]
#1) I'd like to add some words that suggest a user check that the URI that is resolved (or shows up in the To: line of the email message they're about to start typing) in fact matches the URI that is presented.  This check helps users avoid unknowingly sending email to an address that does not match the presented  address.

#2) At least one widely deployed mail app has had problems with the way mailto is associated with the email app.  I'd like to see some text add that addresses how to mitigate the risks associated with: http://www.us-cert.gov/cas/techalerts/TA04-070A.html.

[Ballot comment]
These comments are very minor, but if you are touching the text for some other reason, please consider addressing them:

There are a few SHOULD/SHOULD NOT statements that would benefit from support or further explanation of the consequences of violating them. Perhaps some of them would be better restated without using 2119 language?

Is it possible to say why the  form is NOT RECOMMENDED?

Why isn't "SHOULD be treated as especially suspect" not "MUST be ignored"?
(I'm not suggesting that text change, I'm asking if the document could call out when it might make sense to ignore that SHOULD.

"Programs manipulating 'mailto' URIs SHOULD take great care to..." might be better restructured as advice to implementers without using the 2119 word.

[Ballot discuss]
A really minor point that I hope we can resolve either through you explaining something to me, or through a small tweak to the text...

Section 6.1. is titled "Examples Conforming to RFC 2368". I believe that this section is based on the original text in RFC 2368, but your document is intended to obsolete 2368, so the reference in the title is probably a problem.

How about "Basic Examples" to contrast with sections 6.2 and 6.3?

[Ballot comment]
Please expand acronyms on first use; examples of unexpanded acronyms include "IDNA", "HTML", "XML", and "SMTP".

Please check the document for "URL" instead of "URI" (for example, in Section 2 can be found the text "depending on the context where the URL is used").

In Section 4, is "MAY" meant instead of "may" in the following sentence?

  In cases where the source of an URI
  is well known, and/or specific header fields are limited to specific
  well-known values, other header fields may be considered safe, too.

  (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,
      substantial review has occurred on various IETF lists.

        Does the Document Shepherd have any concerns about the depth or
        breadth of the reviews that  have been performed?

      While this document has received extensive review, it is nevertheless
      the case that it adds some important implementation requirements
      to mailto: URL processors. In particular, section 2, list item 4
      imposes a requirement that mailto: URL processors implement IDNA and
      PunyCode. While it is true that processors for other sorts of URLs
      have similar requirements, mailto: URL processing is often performed
      separately from other URLs. I therefore believe it is important that
      the IESG carefully consider this change and its implications.

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

      The provisions for the handling of Internationalization of the left
      hand side of addresses (section 2 list item 5) should, if it hasn't
      been already, be reviewed by the EAI working group to make sure it is
      consistent with their current view on standards in this area.

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

      Aside from the interntationalization concerns noted above, 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?

      This is a revision of the existing standards for specifying mailto:
      URLs and there appears to be agreement on the changes made in this
      update.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?

      Not that I'm aware of.

        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?

      Aside from the known trust boilerplate issue with xml2rfc, idnits
      reports no problems other than a false positive on the phrase
      "SHOULD not" - this appears in the document revision history.

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

      No.

        If such normative references exist, what is the
        strategy for their completion?

      n/a


        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 the mailto: URL scheme and registers a "dummy"
      body header in the message header registry.

      Are the IANA registries clearly identified?

      Yes.

        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?

      The ABNF in section 2 has been veritied.

      The document contains a large number of example mailto: URLs. These
      have received visual inspection but AFAIK no automatic inspection
      has been performed.

  (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 document defines the format of mailto: Uniform Resource
  Identifiers, (URI), used to identify resources that are reached
  using Internet mail.
  It adds better internationalization and compatibility with IRIs (RFC
  3987) to the previous syntax of 'mailto' URIs (RFC 2368).

      Working Group Summary
 
  This document is not the product of a working group.

      Document Quality

  The documents have been extensively reviewed by people
  with expertise in URIs and email systems.

IANA comments:

ACTION 1:

Upon approval of this document, IANA will make the following
change in the "Uniform Resource Identifer (URI) Schemes" registry at
http://www.iana.org/assignments/uri-schemes.html

OLD:
mailto Electronic mail address [RFC2368]

NEW:
mailto Electronic mail address [RFC-duerst-mailto-bis-09],[RFC2368]


ACTION 2:

Upon approval of this document, IANA will make the following
assignment in the "Permanent Message Header Field Names" registry at
http://www.iana.org/assignments/message-headers/perm-headers.html

Header Field Name | Protocol | Status | Reference
------| ----| ---------| ---------
body | none | | [RFC-duerst-mailto-bis-09]


We understand the above to be the only IANA Actions for this document.

IANA comments/questions:

ACTION 1:

Upon approval of this document, IANA will make the following
change in the "Uniform Resource Identifer (URI) Schemes" registry at
http://www.iana.org/assignments/uri-schemes.html

OLD:

mailto Electronic mail address [RFC2368]

NEW:

mailto Electronic mail address [RFC-duerst-mailto-bis-07]


ACTION 2:

QUESTION: The document uses the word "reserved" in the Status field,
but RFC3868 specifies "standard," "experimental," "informational,"
"historic," and "obsoleted" as the only words that can be used, so
we've left this field blank. Let us know if we should use another
word.

Upon approval of this document, IANA will make the following
assignment in the "Permanent Message Header Field Names" registry at
http://www.iana.org/assignments/message-headers/perm-headers.html

Header Field Name | Protocol | Status | Reference
------| ----| ---------| ---------
body | none | | [RFC-duerst-mailto-bis-07]

Additional comments on -07:

Hi Martin/Larry,
I've requested IETF LC for this document. The following extra comments can be considered as a part of IETF LC.

>2.  Syntax of a 'mailto' URI
>
>  The syntax of a 'mailto' URI is described using the ABNF of [STD68],
>  non-terminal definitions from [RFC5322] (dot-atom, quoted-string) and
>  non-terminal definitions from [STD66] (unreserved, pct-encoded):
>
>      mailtoURI  = "mailto:" [ to ] [ hfields ]
>      to          = [ addr-spec *("%2C" addr-spec ) ]
>      hfields    = "?" hfield *( "&" hfield )
>      hfield      = hfname "=" hfvalue
>      hfname      = *qchar
>      hfvalue    = *qchar
>      addr-spec  = local-part "@" domain
>      local-part  = dot-atom / quoted-string
>      domain      = dot-atom

I think you should be using "dot-atom-text" instead:

  atext          =  ALPHA / DIGIT /    ; Printable US-ASCII
                      "!" / "#" /        ;  characters not including
                      "$" / "%" /        ;  specials.  Used for atoms.
                      "&" / "'" /
                      "*" / "+" /
                      "-" / "/" /
                      "=" / "?" /
                      "^" / "_" /
                      "`" / "{" /
                      "|" / "}" /
                      "~"

  atom            =  [CFWS] 1*atext [CFWS]

  dot-atom-text  =  1*atext *("." 1*atext)

  dot-atom        =  [CFWS] dot-atom-text [CFWS]


I.e. I don't think we want CFWS.

>      qchar      = unreserved / pct-encoded / some-delims
>      some-delims = "!" / "$" / "'" / "(" / ")" / "*"
>                  / "+" / "," / ";" / ":" / "@"

[...]

>  Implementations SHOULD NOT produce two "To:" header fields in a
>  message; the "To:" header field may occur at most once in a message
>  ([RFC5322], Section 3.6).  Also, creators of 'mailto' URIs SHOULD NOT
>  include other message header fields multiple times if these header
>  fields can only be used once in a message.

Any reasons why these SHOULD NOTs are not MUST NOTs?

>From ID-nits:
>
>Miscellaneous warnings:
>  ----------------------------------------------------------------------------
>
>  == The document seems to lack the recommended RFC 2119 boilerplate,
>    even if it appears to use RFC 2119 keywords -- however, there's a
>      paragraph with a matching beginning. Boilerplate error?
>
>    (The document does seem to have the reference to RFC 2119 which the
>
>    ID-Checklist requires).

I think this can be fixed by the RFC Editor, but if you have to do a new revision, you might as well fix that.

AD review completed. The document is in a good shape, but some work on ABNF, [possibly] IANA registration and use of RFC 2119 keywords is needed.