Alternative dereference behavior

This message is pursuant to ACTION-312 which I took on at the F2F.

Roughly speaking, the question is: Does the canon say that the Web is
the authority for http: URI "dereference" (GET), or does it leave open the
possibility of conforming agents using mechanisms that give answers
at variance with what the Web would give?

Definitions (for present purposes):
  "the canon" = current IETF RFCs and W3C recs, including AWWW
  "the Web" = the usual URI/HTTP/DNS/IANA/ICANN combination

I took a look a several documents to see what "the
canon" has to say about this question.

- URI - RFC 3986
  http://www.ietf.org/rfc/rfc3986.txt

    Each URI begins with a scheme name that refers to a specification for
    assigning identifiers within that scheme.  As such, the URI syntax is
    a federated and extensible naming system wherein each scheme's
    specification may further restrict the syntax and semantics of
    identifiers using that scheme.

  Cites BCP35 (informatively).  Doesn't say how to find the registry.

- BCP35 refers to "the IANA URI scheme registry".
  http://tools.ietf.org/html/bcp35

- A search turns up the "IANA URI scheme registry" at
  http://www.iana.org/assignments/uri-schemes.html

  For the 'http' scheme, this cites RFC 2616.

- HTTP - RFC 2616
  http://www.ietf.org/rfc/rfc2616.txt

    3.2.2 The "http" [URL] scheme
    The "http" scheme is used to locate network resources via the
    HTTP protocol. The semantics are that the identified resource is
    located at the server listening for TCP connections on that port
    of that host ...

  (Note: this text is unchanged in HTTPbis revision 07, 2.1.1,
  http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-07#page-11 .)

  This text is written descriptively, not prescriptively, so it
  doesn't rule out *other* ways to use the scheme (e.g. with other
  protocols).  It doesn't give any special status to the HTTP
  protocol regarding http: URIs.  But even if taken as prescriptive,
  it doesn't say anything about a need to use DNS or to use any
  particular DNS root.  Probably these questions were considered to be
  out of scope (as they probably are).

- AWWW
  http://www.w3.org/TR/2004/REC-webarch-20041215/

  2. Identification: "Global naming leads to global network effects."

  I interpret this as saying that unusual dereference is OK as long as
  everyone does it consistently (ha!).

  3.1. Using a URI to Access a Resource.

  This section talks descriptively about how to
  "dereference" a URI, specifically mentioning HTTP.  But the discussion
  is in the form of a descriptive example, not a spec or even a GPN.

  2.2.2.1. URI ownership:

    "The approach taken for the "http" URI scheme, for example, follows the
    pattern whereby the Internet community delegates authority, via the
    IANA URI scheme registry and the DNS, over a set of URIs with a common
    prefix to one particular owner. One consequence of this approach is
    the Web's heavy reliance on the central DNS registry."

  This sentence is descriptive, not prescriptive, although one could
  take the lack of criticism or discussion as some kind of endorsement.
  Taken as prescriptive, it rules out alternative dereference, but I
  don't think it was meant in this way.

  The rest of the section does not seem to bear on the question.

- IAB Technical Comment on the Unique DNS Root
  http://www.icann.org/correspondence/iab-tech-comment-27sept99.htm

    "Allowing multiple public DNS roots would raise a very strong
    possibility that users of different ISPs who click on the same link on
    a web page could end up at different destinations, against the will of
    the web page designers."

    "... if they wish to make use of names uniquely defined for the global
    Internet, they have to fetch that information from the global DNS
    naming hierarchy, and in particular from the coordinated root servers
    of the global DNS naming hierarchy."

  The operative word here is "if".

- RFC 2860 - defines relationship between IETF and IANA (ICANN),
  suggesting (but not saying) that the IANA DNS root has some special status.

- The Self-describing Web
  http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html

  The "standard algorithm" herein specifies use of DNS and HTTP, although
   not the IANA DNS root. (On the other hand this document is not
   written as a spec, and does not act as one. The tone is tutorial and
   descriptive.)

- There has been much community discussion of this topic (see
  e.g. http://esw.w3.org/topic/UriSpaceSquatting ).

Summary:

  . The "normative" documents only describe pieces of the puzzle, not
    how it all fits together, so the question of consistent
    dereference or "meaning" is out of scope in all of them.

  . General advice (AWWW, IAB TC) is that if you "split the web" by making URIs
    non-global you are doing something really tragic.  A change
    in the rules for dereference would theoretically be OK, as long as everyone
    made the change in step (ha!).

Editorializing:

  . The forces that lead to inconsistency would probably not be
    swayed by anyone arguing from a standards perspective, any more
    than you'd expect in any other similar situation of defiance.

  . On the other hand the claim that there's an unbreakable connection
    between http: and unusual dereference is sometimes put forth
    as a reason to stay away from use of http: URIs.

  . It may be useful to try to understand the pressures to diverge
    from the usual stack and to ask whether *any* instances of alternative
    dereference are for the greater good, or at least not harmful to it;
    and to ask if any better alternatives are available to those who
    are departing from the stack, or if they could be created.

  . The various use cases (ISP domain squatting, government policies,
    SmartCache, alternative DNS roots and classes, semweb liberties,
    aggressive user agents or proxies that search caches and archives,
    the persistence "insurance" situation we discussed at the F2F, etc.)
    are not necessarily comparable as the benefits are to
    different actors in each case, and the locus and level of interference
    varies.

Note. I'm well aware of Roy FIelding's "http: isn't HTTP" argument
and don't disagree with it. My question is
about correctness of the answers, not the necessity to use
any particular mechanism.

-Jonathan

Received on Monday, 28 September 2009 17:01:27 UTC