NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 29-Feb-00
Chair(s):
Leslie Daigle <leslie@thinkingcat.com>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>
Applications Area Advisor:
Patrik Faltstrom <paf@swip.net>
Mailing Lists:
General Discussion:cnrp-ietf@lists.internic.net
To Subscribe: cnrp-ietf-request@lists.internic.net
In Body: subscribe
Archive: http://lists.internic.net/archives/cnrp-ietf.html
Description of Working Group:
For the purposes of this working group, a "common name" is a word or a phrase, without imposed syntactic structure, that may be associated with a resource. These common names are expected to be used primarily by humans (as opposed to machine agents). A common name "resolution service" handles these associations between common names and data (resources, information about resources, pointers to locations, etc). A single common name may be associated with different data records, and more than one resolution service is expected to exist. Any common name may be used in any resolution service. Common names are not URIs (Uniform Resource Identifiers) in that they lack the syntactic structure imposed by URIs; furthermore, unlike URNs, there is no requirement of uniqueness or persistence of the association between a common name and a resource.
The working group will define a protocol for the parameterized resolution necessary to make common names useful. "Resolution" is defined as the retrieval of data associated (a priori) with descriptors that match the input request. "Parameterized" means the ability to have a multi-component descriptor. Descriptors are not required to provide unique identification, therefore 0 or more records may be returned to meet a specific input query.
Specific design considerations include
o ensuring applicability across languages and charactersets ("I18N")
o support for federated services: query referral
o facilitating interoperability of CNRP services: e.g., providing base query parameters needed to support common name resolution, as well as the ability to introduce others (and standardize them)
o security: authority, tracking origin of name
The protocol will define:
o client requests/server responses to identify the specific parameters accepted and/or required on input requests
o client request/server responses to identify properties to be returned in the result set
o expression of parameterized input query
o expression of result sets
o standard expression of error conditions
Deliverables:
o Document outlining the goals of common name resolution
o Document specificying a protocol for common name resolution
o Document defining a URI scheme for allowing common names to be embedded in documents
Input documents:
draft-popp-cnrp-00.txt, "A resolution protocol for Common Name Namespaces", Nicolas Popp and Michael Mealling, February 1999.
draft-popp-cnrp-goals-00.txt, "Context and Goals for Common Name Resolution", Larry Masinter, Michael Mealling, Nicolas Popp, Karen Sollins, June 1999.
Goals and Milestones:
Sep 99 |
|
Submit Context and Goals for Common Name Resolution as an Informational RFC. |
Jan 00 |
|
Submit Resolution Protocol for Common Name Namespaces as a Proposed Standard. |
Jan 00 |
|
Draft of common name (resolution protocol) URI scheme |
Mar 00 |
|
Submit common name URI scheme as Proposed Standard |
Apr 00 |
|
Close working group. |
Internet-Drafts:
No Request For Comments
CNRP, 47th IETF, April 30, 2000
Reported by: Ted Hardie
Leslie Daigle chaired the meeting; after reviewing the agenda and the current status of the working group, Marshall Moseley presented the protocol draft.
Terminology change--results are now resource descriptors; the results are an ordered list of decreasing lists; supports a subset ordering.
Discussion of security considerations was split into issues related to Man-in-the middle and other server spoofing issues. In the first case where there is transport level authentication, that is used. For non-authenticated transports, signing the server object and public key description. DoS attacks were raised as an issue and the group agreed that the draft should discuss the problem that adding a level of indirection for resolution raises for attacks on protocols which rely on the resolution.
Nico Popp then discussed the extensibility model. Properties are the main building blocks. There are three types: Core (those with their own tag, commonName, resourceURI, ID); abstract property; base properties (language, geography, category, description, range). Extensibility through new properties and loosely typed objects. You cannot create new objects from scratch, just properties. There are two property creation mechanisms. The first is to create new propertyname; the second is to create a new property type for an existing property name. The authors are proposing that types be scoped to individual properties; when a new property is created, the types allowed must be listed and it is not possible to include "all" or "any". This scheme means that one effect of the second method of creating a property modify the type of allowed response for the property; this is not creating a property tuple of name and type. This does mean that real collisions of property names are possible, but the the type scope limits the effect of this collision.
There are some terminology changes in schema discovery as a result of the different approach to property creation mechanisms.
Michael Mealling then presented property and tag registration. These will be registered with IANA. If locally defined, they must begin with x-. If you register a type, you must indicate to which properties it applies.
Michael then discussed status messages and went through possible messages; the authors currently believe that 3 digit codes will suffice (RFC 821 style) as most status messages have more to do with the transport than CNRP. A brief discussion of IANA's scope was put forward; there was then a brief discussion of the advisibility of registering status code. James Seng was of the opinion that an extensible registry was a problem for implementors, as they must then keep track of the registry's contents. Ted Hardie presented the contrary position that it was a valuable method for avoiding collision and that it did not present new requirements for implementor's compliance with the spec. The authors agreed to put forward a proposal to the list, and the chair urged those concerned to review it.
URI syntax was then presented by Michael Mealling. Two forms presented:
cnrp://<host>/<path>?<cN>[;<attr>=<value>]*
cnrp:<common-name>[;<attribute>=<value>]*
Not clear if 2396 allows the second form; there is an or in the spec which seems to indicate that you can have either a hierarchical form or opaque string form, but not clear if they can be mixed. A user/name password can be put into the host part. The authors then took up the question of what it means when a host part is absent. The initial suggestion was "localhost". Discussion indicated it was unclear how the path part fit into this--is this a service-specific element. The answer is yes, but agreement on the meaning of path elements might emerge.
The group agreed that if the first form were used with a host, then the localhost would be queried. The authors will re-write the draft to elucidate the no-host aspects and discuss the use of the path part in this URL scheme. The authors also clarified that the URI represents a query, rather than a record or the result set from a query.
Michael then brought up the transport independence problem: if the URI cnrp:, what transport protocol should be used? Possible solutions: naptr, no transport independence, create new transport, use bxxp only, use an srv-like DNS record to look this up, use rescap, or specify http as mandatory element at which the service schema can be advertised. There was a rollicking discussion of how the transport independence could be retained for the purpose of large-scale systems, while retaining interoperability.
Leslie asked for consensus on HTTP as a manadatory to implement service, but that the group would leave the protocol in the DTD so that it could be specified as other than HTTP for specific services at some later time. Leslie took checking on the status of the goals document in the IESG queue as an action item. She then reviewed the action items emerging from the group:
- finalize discussion of status message on mailing list;
- documenting the IANA registration of properties and types;
- revise the protocol and uri documents to reflect the discussion here.
The discussion on the mailing list will begin by April 21st; the aim of the group is to begin document revision by May 15th. The group should close down by the Pittsburgh IETF.
None received.