On Tue, May 14, 2013 at 10:16 PM, Anne van Kesteren <[email protected]> wrote: > On Tue, May 14, 2013 at 2:03 PM, Jason Orendorff > <[email protected]> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
