Module naming and declarations
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.
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
By your own example
there are URLs with schemes that are not absolute. This contradicts
your WHATWG document which purports to reflect browser
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
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.
the "url" input element type attribute as producing "An absolute URL"
Applications will rely on this type when processing.
that other link types having a COLON ":" must be absolute URLs.
WHATWGML's @itemprop tokens
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
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
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
RFC 4468 "Message Submission BURL Extension" defines a new SMTP
command to retrieve data from an absolute IMAP URL
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
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
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.
More information about the es-discuss