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 property
name; 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.