I’m using this space to share some of the collected artifacts found in digging through archives of past work on Internet technology development.\u00a0 Several pieces are available publicly elsewhere — if you know they exist and where to look for them.\u00a0 This is the sort of thing you might find when digging around in “the attic” of an old farm house, for instance.<\/p>\n
Here are some of the topics I have\/plan to cover (topics already covered are linked):<\/p>\n
1990’s:<\/p>\n
2000’s:<\/p>\n
2010’s:<\/p>\n
<\/p>\n
IAFA stands for “Internet Anonymous FTP Archive”, and IAFA templates were being developed at the IETF in the early 1990’s, as a first effort in machine-parsable “metadata” for Internet resources, in the then-current publication platform of the Internet (Anonymous FTP).<\/p>\n
You can see a snapshot of the definition of the intended standard in:\u00a0 draft-ietf-iiir-publishing-03.txt<\/a> .\u00a0 The abstract of that document reads:<\/p>\n Anonymous FTP Archives are a popular method of making A couple of interesting historical points:<\/p>\n (National) librarians were heavily involved in figuring out indexing and archiving of Internet material at that time — seeing the Internet as a publication medium and wanting to address its publications.\u00a0 Further efforts with IAFA templates included mappings to US Library of Congress MARC codes.\u00a0 (MARC is “MAchine Readable Cataloging”).<\/p>\n The IAFA Templates work probably represents the first serious effort of Internet standards in metadata systems.<\/p>\n <\/p>\n URCs have their own Wikipedia page!<\/a>\u00a0\u00a0 This sums it up pretty well:<\/p>\n “A URC binds a URI’s associated URN (uniform resource name<\/a>, a unique name for a Web resource) to its URL (uniform resource locator<\/a>, the location at which a Web resource can be found). [1]<\/a><\/sup> URCs were proposed as a specification<\/a> in the mid-1990s, but were never adopted.”<\/p>\n According to the IETF website, there was a URC Working Group<\/a>, which concluded in January 1997.\u00a0 I don’t recall it actually getting off the ground, but that may be a fault of my recollection.<\/p>\n UKOLN has a good summary of the way things were,<\/a> including:<\/p>\n “It is important to note that there is (currently) no URC per se<\/i>. The term URC has generally been used to identify:<\/p>\n \u00b7 long term cataloguing information pertaining primarily to on-line resources<\/p>\n \u00b7 a standardised means of associating so-called metadata<\/i>, or describing information, with objects – not necessarily for cataloguing purposes<\/p>\n \u00b7 information used as part of the process of resolving a Uniform Resource Name (URN) to a URL or URLs<\/p>\n \u00b7 information used by applications when selecting a particular instance of a resource from a number of possibilities, not necessarily as part of a URN lookup.<\/p>\n URCs started off life as the responsibility of the Internet Engineering Task Force’s Uniform Resource Identifiers working group, which was chartered to investigate both URCs and Uniform Resource Names (URNs) – persistent location independent naming. In an unusual step for the IETF, the URI group was disbanded due to what was felt to be a lack of progress.<\/p>\n At the time of writing, an effort was under way to form a new IETF working group specifically addressing URC issues, and with a more focussed remit than the old URI group. Specifically: the new group would focus on developing a common carrier architecture which could be used to package various resource description formats, rather than attempting to standardise upon one particular preferred format.”<\/p>\n Looking back on it, I would say that there was an inherent tussle between the cataloguers (honest-to-goodness librarians, who knew about creating indexes of materials) and the application engineers (who wanted a way to capture application-relevant information, such as media type).\u00a0 The problem was that the latter never really closed on a fixed set of uses for this “metadata”.<\/p>\n <\/p>\n In the late 1990’s, there was interest in being able to determine the “capabilities” of an Internet-connected resource.\u00a0 This is sort of like URCs, but in some ways the focus was more on services as a resource, whereas URCs were inherently tied to the notion of resources being “pages” or “documents”.<\/p>\n So, for example, if you wanted to know whether a given e-mail address would accept MIME-encapsulated content (as opposed to plaintext only), you might look up the resource’s capabilities to find out.\u00a0\u00a0 Today, that might seem like a bit of a contrived example;\u00a0 we don’t live in nearly as technology-constrained an environment as existed 15 years ago.\u00a0\u00a0 But, the concept does generalize to things we’re interested in today — e.g., does this phone number accept text messages?<\/p>\n My notes from c2000 say:<\/p>\n “RESCAP An IETF WG was formed — you can see its charter here<\/a>, but the work was never finished.\u00a0\u00a0 An IESG note on one of the WG’s documents reads:<\/p>\n “Open issues not resolved after 18 months. WG concluded. Marking dead.”<\/p>\n \u00a0That describes what happened, but I think it obscures some of why<\/em> it happened.\u00a0 Indeed, there were 2 basic proposals on the table, and the two driving technology minds did not come to agreement on how to bring them together.\u00a0 The working group didn’t pick one.\u00a0\u00a0\u00a0 But, fundamentally, there was a lack of energy and focus — without a significant drive toward adoption of the result, the WG consisted of a couple of interested idea editors and some interested bystanders (myself included).\u00a0\u00a0\u00a0 Eventually, attention waned and we all wandered away.<\/p>\n Some of the documents worth reviewing are:<\/p>\n <\/p>\n Historically, two pressures on the DNS have been:\u00a0 the desire to control recognizable strings stored in it, and the habit of sticking all manner of things in it (because it is a universally-accessible, federated, distributed system that actually works).\u00a0\u00a0 Along with the “recognizable” string hysteria, there has long been an impression that the DNS should somehow support “search”, which is not actually what it’s built for.<\/p>\n As an effort to address that desire (searching for labels of Internet things, and tying them back to the DNS), John Klensin spearheaded work on addressing the issue with a layer above the DNS.<\/p>\n Last updated 2004.\u00a0\u00a0\u00a0\u00a0 See https:\/\/datatracker.ietf.org\/doc\/draft-klensin-dns-search\/<\/a> for the Internet-draft and its history.\u00a0\u00a0 The abstract reads:<\/p>\n This memo discusses strategies for supporting ‘DNS searching’ — finding of names in the DNS, or references that will ultimately point to DNS names, by a mechanism layered above the DNS itself that permits fuzzy matching, selection that uses attributes or facets, and use of descriptive terms. Demand for these facilities appear to be increasing with growth in the Internet (and especially the web) and with requirements to move beyond the restricted subset of ASCII names that have been the traditional contents of DNS ‘Class=IN’. This document proposes a three-level system for access to DNS names in which the upper two levels involve search, rather than lookup (exactly known target), functions. It also discusses some of the issues and challenges in completing the design of, and deploying, such a system.<\/p><\/blockquote>\n <\/p>\n <\/p>\n Circa 2000.<\/p>\n From memory, this was only ever an IETF BoF.\u00a0 The data tracker lists it as a “concluded working group”: http:\/\/datatracker.ietf.org\/wg\/c15n\/charter\/<\/a><\/p>\n The URN WG’s Dynamic Delegation Discovery System (DDDS) describes a The BoF (December 2000) had an agenda — http:\/\/www.ietf.org\/ietf-ftp\/00dec\/c15n-agenda.txt .<\/a>\u00a0\u00a0 I had some slides:\u00a0 LLD-c15n<\/a> .\u00a0 None of these made it into the official proceedings from that IETF meeting, for reasons unclear this many years later.<\/p>\n There were other presentations from other people.\u00a0 I can’t find any official minutes or drafts thereof.\u00a0 I have an empty “c15n” folder in my mailbox hierarchy — don’t know if it was lost to random IMAP errors over the years, or if it was an unfulfilled expectation.<\/p>\n My rough notes (which I won’t reproduce here \ud83d\ude42 ) suggest the meeting concluded with mild support to progress toward a working group.\u00a0 But not a whole lot of energy or volunteers to carry it forward.<\/p>\n","protected":false},"excerpt":{"rendered":" I’m using this space to share some of the collected artifacts found in digging through archives of past work on Internet technology development.\u00a0 Several pieces are available publicly elsewhere — if you know they exist and where to look for them.\u00a0 This is the sort of thing you might find when digging around in “the […]<\/p>\n","protected":false},"author":2,"featured_media":0,"parent":0,"menu_order":7,"comment_status":"open","ping_status":"closed","template":"","meta":{"jetpack_post_was_ever_published":false,"footnotes":""},"class_list":["post-214","page","type-page","status-publish","hentry"],"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/PbjRsG-3s","_links":{"self":[{"href":"https:\/\/www.thinkingcat.com\/wordpress\/wp-json\/wp\/v2\/pages\/214","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.thinkingcat.com\/wordpress\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.thinkingcat.com\/wordpress\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.thinkingcat.com\/wordpress\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.thinkingcat.com\/wordpress\/wp-json\/wp\/v2\/comments?post=214"}],"version-history":[{"count":10,"href":"https:\/\/www.thinkingcat.com\/wordpress\/wp-json\/wp\/v2\/pages\/214\/revisions"}],"predecessor-version":[{"id":217,"href":"https:\/\/www.thinkingcat.com\/wordpress\/wp-json\/wp\/v2\/pages\/214\/revisions\/217"}],"wp:attachment":[{"href":"https:\/\/www.thinkingcat.com\/wordpress\/wp-json\/wp\/v2\/media?parent=214"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nmaterial available to the Internet user community. This
\ndocument specifies a range of indexing information that can
\nbe used to describe the contents and services provided by
\nsuch archives. This information can be used directly by the
\nuser community when visiting parts of the archive. Further-
\nmore, automatic indexing tools can gather and index this
\ninformation, thus making it easier for users to find and
\naccess it.<\/p>\n<\/a>Uniform Resource Characteristics (URC)<\/h3>\n
<\/a>RESource CAPabilities — RESCAP<\/h3>\n
\n. all about finding ‘capabilities’ of a ‘resource’
\n. currently based on ‘the hostname of the url’
\n. uses DNS to find the rescap server”<\/p>\n\n
<\/a>DNS Search<\/h3>\n
<\/a>Contextualized (URI) Resolution — C15N<\/h3>\n
\ngeneralized architecture for ‘top down’ resolution of identifiers such
\nas URIs. This works well when a (software) client wants or needs to
\ndynamically determine the explicit authoritative delegation of
\nresolution. However, there are times when it is desirable to
\nincorporate other elements of contextual control information in
\ndetermining, for example, the “appropriate copy” of a resource —
\npreferrentially finding a “local” copy of a journal rather than
\nre)purchasing one from the authoritative publisher. This is generally
\napplicable to all URI resolution, but it is more specific than “web
\ncaching”. Software systems being built to solve this in today’s
\ndeployed systems are using specialized, non-interoperable, non-
\nscalable approaches.<\/p>\n