Use of authority in discover

Issue #1013 resolved
Tom Jones created an issue

Section 2.1 of the discover document includes a port number on the authority based on the URI RFC (see below). Unfortunately this is not consistent as no scheme in wide use allows this behavior, and AFAICT there was no standard scheme in place that allowed it at the time RFC 3936 was written. In general a URI MUST have a scheme. The real problem is that since the scheme mailto: does not allow a port number, it is not practically possible for a user at a computer to enter a user name that contains a port number. I strongly recommend that port numbers in authorities be removed since it is not possible in practice to discover the port number.

NOTE: Since the definition of authority in RFC 3986 [RFC3986] is [ userinfo "@" ] host [ ":" port ], it is legal to have a user input identifier like userinfo@host:port, e.g., alice@example.com:8080.

Comments (7)

  1. Michael Jones

    We discussed this on the 13-Apr-17 working group call. The first observation is that port numbers are only likely to be used during debugging. Second, while the acct: URI spec http://mail.tools.ietf.org/html/rfc7565 doesn't make accommodations for port numbers, in practice, several implementations do allow :port to follow the hostname in acct: URI values, again to facilitate debugging. We recommend allowing this practice, even though it's not strictly specification compliant.

  2. Tom Jones reporter

    I strongly disagree. I write complex deployment ready code, it is a major hassle to add this functionality solely for the purposes of certification. Debugging code should NOT be covered in the spec. Besides the fact that it is NOT A LEGAL URI, in spite of the occurrence in the URI spec - which I consider to be a bug (inconsistency) in that spec.

  3. Michael Jones

    As you point out, in the issue description, RFC 3986 does say that URIs can contain ports. See https://tools.ietf.org/html/rfc3986#section-3.2.3 . Given that the normalization rules in Section 2.1 are written in terms of RFC 3986 syntax, I believe that the text is correct as it stands. I believe that no change to the text cited is warranted as part of the errata process.

  4. Log in to comment