Internet DRAFT - draft-daigle-appidarch
draft-daigle-appidarch
Internet Engineering Task Force L. Daigle
Internet-Draft TCE
Intended status: Informational March 2015
Expires: August 31, 2015
Internet Application Identifier Architecture
draft-daigle-appidarch-00.txt
Abstract
This document outlines a general architecture for Internet
applications, through the perspective of applications identifiers.
It provides a survey of past approaches, drawing out common elements
and highlighting common traps and roadblocks.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 31, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Basic components of Application Identifier Architecture . . . 2
3. Application Identifier Architectures in More Detail . . . . . 2
3.1. System . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Daigle Expires August 31, 2015 [Page 1]
Internet-Draft App ID Arch March 2015
3.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Identified . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Survey of existing work . . . . . . . . . . . . . . . . . . . 5
4.1. Domain Name System . . . . . . . . . . . . . . . . . . . . 5
4.2. World Wide Web . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Classic URIs . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. IP addresses . . . . . . . . . . . . . . . . . . . . . . . 10
5. Common design choices and challenges . . . . . . . . . . . . . 10
5.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Identified . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Issues in (mis)using identifiers . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
This document posits a high level architecture of Internet
application identifier systems, as well as a survey of IETF efforts
dealing in standardization of Internet applications and services
using those identifier systems.
Status of this revision: this is a very drafty -00 document. The
hope and expectation is that it is enough to stimulate some thought
and discussion to flesh out future documents.
2. Basic components of Application Identifier Architecture
There are 3 basic components of an Application Identifier
Architecture:
o System
o Identifiers
o Identified
The System is the context in which the identifiers are created, used
and in which they are intended to make sense. This is usually
transparent, except when identifiers are used outside of this
context, causing greater or lesser problems over time. This is
discussed in more detail, below.
Identifiers are typically strings of bits or characters. They may
have multiple representations.
The concept of what is being Identified is also dependent on the
System -- whether it's Internet hosts, services, documents, parts of
documents, people or other actors from the physical world, their
representatives in the Internet, etc.
3. Application Identifier Architectures in More Detail
3.1. System
Daigle Expires August 31, 2015 [Page 2]
Internet-Draft App ID Arch March 2015
As noted above, the System is the context in which the identifiers
make sense. In the Domain Name System, for example, the system
initially consisted of the set of hosts attached to the Internet, and
it has generalized to the set of addressable Internet services.
These are organized into ?domains?, which are operated under the
control of a single entity, and individual domains are completely
independent of each other.
3.2. Identifiers
Identifiers may identify a thing that exists ? content, service,
location ? or is posited to exist. Typical actions on identifiers
include:
o "Minting" -- creation of an identifier, usually including
association with the identified thing
o Transformation -- changing the bits (characters) of the identifier
by some set of rules and/or to conform to some structure; relative
or absolute
o Comparison -- of identifiers. Are 2 different identifiers the
same? Identifying the same thing? Expressing relationship
between things?
o Resolution -- using the identifier to access what it identifies
o Validation -- confirmation that the identifier conforms to the
system?s rules (syntax)
o Status check -- has the identifier been minted? Is it active
within the system?
o Authentication -- confirmation that the identifier association is
valid (as minted)
o Lookup -- some systems support look up ? finding identifier
entries based on partial fragments, typically leading characters
(bits)
o Search -- some systems support searches for identifiers based on
fragments of the related data
o Subscribe -- subscribing to an identifier allows you to get
periodic updates as to state of the identifier/identified.
3.3. Identified
Identifiers can be associated with just about any level of concept,
construct, network or software element, or entity in the physical
world. The range of possible identified things is generally scoped
by the System.
Daigle Expires August 31, 2015 [Page 3]
Internet-Draft App ID Arch March 2015
From the perspective of application architectures, there are 4 levels
of things that may be identified, and may have individual
identifiers:
o Entity/resource -- the thing itself. For example, the published
work "Moby Dick"
o Instance -- a specific copy of the thing, e.g., a copy of "Moby
Dick".
o Properties -- the characteristics of the thing. The set of
properties discussed is generally constrained by the System.
o Relationship -- an identifier may identify something as "part-of"
a larger entity.
There are actions that may be performed on the things identified:
o Assign properties -- associate values with properties of
identified item
o Get properties
o Intrinsic -- E.g., format, number of words
o Applied -- director's cut
o Publish -- put copy somewhere
o First instance
o Cache/replica
o Get (a copy)
o Any copy
o Specific service
o Closest
o Cheapest
o Authenticate -- confirm (cryptographically) that the resource is
genuinely the one expected / related to identifier
o Comparison
o Equivalence
o Send -- a reflection of "get"?
o Subscribe
Daigle Expires August 31, 2015 [Page 4]
Internet-Draft App ID Arch March 2015
o Search
4. Survey of existing work
4.1. Domain Name System
The Domain Name System (DNS) was designed to provide identifiers to
allow storage and retrieval of (sets of) properties associated with
Internet hosts and services ? real and virtual.
DNS identifiers are hierarchical, dot-separated labels, typically
expressed as characters. Host names are a subset of domain name
identifiers, with some restrictions on the permissible characters.
o "Minting" -- the authority for a domain can create labels within
that domain. So-called "synthetic" domain labels are created
dynamically.
o Transformation -- relative domain names can be understood within
the context of a ?search domain?
o Comparison -- domain names are matched on an octet-by-octet basis
(IDNs are not considered here)
o Resolution -- DNS resolution means "DNS lookup" -- using the DNS
infrastructure to retrieve resource records associated with the
domain name. Resolution can be tailored to retrieve particular
types of resource records (e.g., A records, or AAAA records, or MX
records)
o Validation -- any string that conforms to DNS syntax may be
considered valid.
o Status check -- DNS does not distinguish between "inactive" and
"not minted". That is, either every label in the hierarchical
domain name is accessible in an authoritative domain server (in
which case the domain name is "minted" and "active") or the DNS
will return the value that it does not exist. (Not true in
DNSSEC?)
o Authentication -- domain names are not authenticated (see below
for DNSSEC).
o Lookup -- DNS resolution is lookup of domain names
o Search -- DNS does not support search (wildcards?)
o Subscribe -- N/A
DNS identifies resource records. The resource records are
themselves descriptions of Internet hosts, services, and other
Daigle Expires August 31, 2015 [Page 5]
Internet-Draft App ID Arch March 2015
information stored in the DNS, but fundamentally the DNS identifier
is for resource records.
o Entity/resource -- a set of resource records
o Instance -- copies of resource records may be stored in caching
servers; there are no special identifiers to distinguish primary
or cached results
o Properties -- N/A
o Relationship -- N/A
There are actions that may be performed on the things identified:
o Assign properties -- resource records have time to live (TTL) and
serial numbers included
o Get properties -- parsed as part of the response from the server.
o Publish -- publishing a DNS resource record amounts to updating a
DNS zone file with the record.
o Get (a copy) -- resolve the domain name identifier
o Authenticate -- DNSSEC is used to authenticate that the resource
records/response received for domain name resolution are as they
were published.
o Comparison -- of RRs?
o Send -- N/A
o Search -- N/A
4.2. World Wide Web
The World Wide Web (WWW) is largely defined by the HTTP protocol.
"Pages" defined in HTML are the primary design target, though these
days much content of varying formats is delivered via the HTTP
protocol. For the sake of discussion, we'll say that WWW identifiers
are HTTP scheme URIs.
o "Minting" -- typically, HTTP URIs are not composed consciously, so
much as assembled practically with components of the domain name
hosting the web server and some path components based on how the
website is laid out hierarchically (which may or may not relate to
Daigle Expires August 31, 2015 [Page 6]
Internet-Draft App ID Arch March 2015
an underlying file structure)
o Transformation -- HTTP URIs may be relative (to current page in
the "hierarchy", current domain authority etc)
o Comparison -- HTTP URIs are not inherently comparable except by
characterwise comparision or determining relative relationships
o Resolution -- HTTP URIs are resolved by parsing the authority
component from the URI, connecting to the server, and requesting
the resource associated with the path part of the URI.
o Validation -- any string that conforms to HTTP URI syntax may be
considered valid.
o Status check -- HTTP does not distinguish between "inactive" and
"not minted". That is, either the HTTP server is available and
the resource is found on it (in which case the URI is "minted" and
"active") or the server (or path) are not found.
o Authentication -- HTTP URIs are not authenticated (see below for
authentication of servers).
o Lookup -- N/A
o Search -- HTTP does not support search (within server?)
o Subscribe -- N/A
HTTP URIs identify "web pages" or "resources".
o Entity/resource -- web content (page)
o Instance -- copies of pages may be stored in caching servers;
there are no special identifiers to distinguish primary or cached
results
o Properties -- properties may be embedded within the HTML document,
but there are no special identifiers to query/retrieve properties;
as part of the HTTP protocol, capabilities may be negotiated
o Relationship -- relative URIs (?)
There are actions that may be performed on the things identified:
o Assign properties -- the web server may assign properties to a web
page.
o Get properties --parsed as part of the response from the server.
o Publish -- publishing a web page is done on the backend, out of
band of the WWW system
o Get (a copy) -- resolve the URI
Daigle Expires August 31, 2015 [Page 7]
Internet-Draft App ID Arch March 2015
o Authenticate -- certs are used, within HTTP, to authenticate the
server is empowered to operate for a given domain name.
Individual pages are not authenticated.
o Comparison -- many web pages look alike -- but there is no
inherent way to claim two web pages (documents) are "the same".
o Send -- N/A
o Search -- within the WWW there is no support for search (all
search is achieved as an external system).
4.3. Classic URIs
The advent of the WWW heralded a burst of development of standards
for applications and content on the Internet. Much work was done to
elaborate a general system of identifiers, supporting a broad range
of application needs -- Uniform Resource Identifiers in the large,
encompassing Locators (identifiers of Internet "location"), Names
(persistent, location-independent identifiers for resources),
Characteristics (metadata about resources), Agents (for composing
actions).
In the large, the classic perspective on URIs was that they would
identify all resources (documents, services, media, components,
classes, parameters etc) that would be referenced within Internet
protocols.
o "Minting" -- dependent on the URI scheme. The HTTP URI scheme is
outlined above as a dynamic URI creation example. Some
(namespaces of) URNs require more explicit minting of identifiers
to be used in URNs (e.g., ISBN URNs).
o Transformation -- dependent on the URI scheme. URNs were
intended to be (authoritatively) transformed into URLs identifying
the location of the desired resource at a given point in time.
o Comparison -- Scheme-dependent -- there is no URI-wide support for
comparing URIs (except byte-wise equality).
o Resolution -- Scheme-dependent. Some URI schemes do not have
Internet-based resolution capabilities.
o Validation -- any string that conforms to URI syntax may be
considered valid. Individual schemes may include validation
services (e.g., out of band lookup services, built-in checksums,
etc).
o Status check -- Generally, URIs do not distinguish between
"inactive" and "not minted". That is, successful resolution
Daigle Expires August 31, 2015 [Page 8]
Internet-Draft App ID Arch March 2015
implies minted, unsuccessful resolution is ambiguous. Individual
schemes may provide more refined methods of confirmation of status
(SIP URIs?)
o Authentication -- There is no URI-wide support for URI
authentication.
o Lookup -- N/A
o Search -- URIs are not inherently searchable
o Subscribe -- N/A
Classically, URIs identify Internet "resources". However, URIs
have been found in contexts that are disjoint from the Internet
(e.g., XML component identification). "Resource" is deliberately
general -- could be documents, services, etc. Each URI scheme
refines its scope of intended resources.
Entity/resource -- typically Internet content or service, but see
comment above.
Instance -- Most URI schemes do not support identification of
instances. However, URNs are intended to identify locations of
multiple instances of a given resource.
Properties -- URIs may identify URCs (Uniform Resource
Characteristics) an articulation of the properties of a given
resource. (URCs were never finally standardized).
Relationship -- relative URIs (?)
There are actions that may be performed on the things identified:
o Assign properties -- publish a URC
o Get properties -- retrieve a URC associated with the URI.
o Publish -- scheme-dependent
o Get (a copy) -- resolve the URI
o Authenticate -- certs are used, within some URI schemes, to
authenticate the server is empowered to operate for a given domain
name. Individual resources are not authenticated. (Unless you
have a URC with a checksum?)
o Comparison -- many resources look alike -- but there is no
inherent way to claim two resources are "the same".
o Send -- N/A
o Search -- within the URI space there is no support for search (all
search is achieved as an external system).
Daigle Expires August 31, 2015 [Page 9]
Internet-Draft App ID Arch March 2015
4.4. IP addresses
To be added... the interesting thing about IP addresses is
considering the context in which they are defined, and then
contrasting that with the places they turn up.
5. Common design choices and challenges
In creating a system, there are important common design choices that
need to be made. Sometimes the answer is implicit within the overall
design constraints of the system. Other times, considerable effort
is required to refine specifications and make appropriate choices.
As noted, these are common design questions. This is an area where
understanding of previous systems? design discussions can be
particularly helpful (in order not to repeat them needlessly).
5.1. Identifiers
In defining identifiers for a system, is the intention that they:
o Name something -- the identifier will be associated with one
entity (or instance of an entity), wherever that entity may be
located.
o Locate something -- identify the location of an entity (at some
point in time).
o Are Smart or dumb identifiers -- "smart" identifiers have
structures that can be parsed to determine something about the
thing identified (e.g., domain in which it is stored); "dumb"
identifiers are opaque and must be resolved within the system.
o Have uniqueness -- is the identifier/resource binding unique?
o Have scope -- is the uniqueness (or other properties) only
maintained within some limited scope, or is it global?
o Permanent -- what is the expected level of permanence of the
identifier's relevance (the ability to use it, the binding between
the identifier and the identified resource). Or, are they
transient identifiers?
5.2. Identified
The specifics of the identified resource need to be defined, as well.
o Instances -- can there be multiple instances of a single resource?
How can they be distinguished and/or how can two instances be
equated. This is important if one needs to be able to cache
instances or otherwise validate "local" copies.
o Scope of applicability -- what constitutes a "resource" in this
system?
Daigle Expires August 31, 2015 [Page 10]
Internet-Draft App ID Arch March 2015
6. Issues in (mis)using identifiers
Things like using IP addressed out of context of the routing system ?
assumptions about uniqueness and volatility may be improper.
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
This document is about considering applications systems. Security is
important to applications, but is not specifically called out here.
9. References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997, <http:/
/xml.resource.org/public/rfc/html/rfc2119.html>.
Author's Address
Leslie Daigle
ThinkingCat Enterprises
Leesburg, VA 20176
US
Email: ldaigle@thinkingcat.com
Daigle Expires August 31, 2015 [Page 11]
