Module naming and declarations

David Sheets kosmo.zb at gmail.com
Tue May 14 16:39:32 PDT 2013


On Tue, May 14, 2013 at 10:16 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Tue, May 14, 2013 at 2:03 PM, Jason Orendorff
> <jason.orendorff at gmail.com> wrote:
>> I found a standard that defines this!
>>
>> "An absolute URL is a URL with a scheme."
>
> That doesn't mean we use this concept in the platform anywhere.

Dear Anne,

Though this does not directly bear on the module discussion at hand, I
have tired of your continued spreading of misinformation regarding
URIs. Surely you must be mistaken in your repeated assertions against
the fixed notion of absolute URL? Perhaps you mean no decision
procedure exists for relative-scheme URL absoluteness? I believe such
a procedure does exist and you have already attempted to specify it.

In your own document, you define a "base URL" as an absolute URL
<http://url.spec.whatwg.org/#concept-base-url>.

By your own example
<https://mail.mozilla.org/pipermail/es-discuss/2013-May/030557.html>,
there are URLs with schemes that are not absolute. This contradicts
your WHATWG document which purports to reflect browser
implementations.

Though it <https://mail.mozilla.org/pipermail/es-discuss/2013-May/030559.html>
is not a mathematically constructive definition, a very concrete
definition of absolute URI as universal fixpoint exists. I am certain
that a constructive definition also exists. In fact, you have already
specified one.

The primary use of "absolute URLs" is *unambiguity* (aside: many specs
refer to URIs as if they are all absolute and use the term "relative
URI" or "relative reference" for non-absolute URIs). They are widely
used and their properties relied upon in many documents, programs, and
interfaces. Your own parsing/normalizing/resolving procedure in your
URL document *only* defines a representation for absolute URLs:
"Parsing (provided it does not return failure) and serializing a URL
will turn it into an absolute URL."

There are many standards that do not define relative resolution of URL
references and instead require an absolute URL.

Many of these standards seem to get by with a reference to STD66's
absolute URI ABNF production.

To wit:

WHATWGML defines
<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#attr-input-type-keywords>
the "url" input element type attribute as producing "An absolute URL"
<http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#url-state-%28type=url%29>.
Applications will rely on this type when processing.

WHATWGML mandates
<http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#other-link-types>
that other link types having a COLON ":" must be absolute URLs.

WHATWGML's @itemprop tokens
<http://www.whatwg.org/specs/web-apps/current-work/#names:-the-itemprop-attribute>
for typed items may be absolute URLs but not relative URL references.

RFC 4395 "Guidelines and Registration Procedures for New URI Schemes"
requires  <http://tools.ietf.org/html/rfc4395#section-2.2> new schemes
define absolute syntaxes and avoid notation used by relative schemes
for relative references.

XML namespaces, XPath, etc also use absolute URLs
<http://lists.w3.org/Archives/Public/xml-uri/2000Sep/0083.html>.

RFC 3404 "DDDS" only <http://tools.ietf.org/html/rfc3404#section-4.1>
resolves absolute URLs.

RFC 2326 "RTSP" requests use
<http://tools.ietf.org/html/rfc2326#page-21> absolute URLs only.

RFC 5842 "WebDAV Binding Extensions" use absolute URIs in URI Mappings
<http://tools.ietf.org/html/rfc5842#section-1.1>.

Maximally interoperable server implementations of the HTTP 1.1 (RFC
2616) Location header
<http://tools.ietf.org/html/rfc2616#section-14.30> emit only absolute
URLs.

RFC 4468 "Message Submission BURL Extension" defines a new SMTP
command to retrieve data from an absolute IMAP URL
<http://tools.ietf.org/html/rfc4468#section-3.5>.

RFC 6749 "OAuth 2.0 Authorization Framework", though troubled,
requires absolute URLs for endpoints
<http://tools.ietf.org/html/rfc6749#section-3.1.2> as well as
extension grant types <http://tools.ietf.org/html/rfc6749#section-4.5>
and access token types
<http://tools.ietf.org/html/rfc6749#section-8.1>.

RFC 6066 (proposed) "Transport Layer Security (TLS) Extensions:
Extension Definitions" defines
<http://tools.ietf.org/html/rfc6066#section-5> client certificate URLs
that must be absolute.

RFC 6134 (proposed) "Sieve Extension: Externally Stored Lists" for
email filtering defines the name of externally stored lists
<http://tools.ietf.org/html/rfc6134#section-2.5> as always an absolute
URI.

This is only a partial list from a short bout of research. I'm sure if
you exert yourself, you will discover that you were mistaken.

Sincerely,

David


More information about the es-discuss mailing list