2.1.13 Common Name Resolution Protocol (cnrp) bof

Current Meeting Report

Minutes taken by Nico Popp, edits by Larry Masinter
The meeting was chaired by Cliff Lynch.

The meeting started with a review for why the BOF changed names: The previous BOF on "Human Friendly Names" seemed like it would deep-end on the discussion of "what made a name friendly" and "were URLs friendly?" and "are telephone numbers friendly"? But the goal wasn't to _define_ friendly names, but rather, create a standard protocol for resolving them. Because "common name" is a common name for what we're talking about, we used "common name resolution protocol" to focus the group.

Larry Masinter presented the draft charter (circulated on mailing list) and gave a brief overview of the papers that were submitted:

Mealling: Requirements for HFNs
Popp: The RealName system and hoiw it maps to URLs and URNs
Moseley: Architecture & requirements
Other relevant documents:
RFC2345 Domain Names and Company Names retrieval
RFC2517 Building Directories from DNS: Experiences from WWWSeeker

Charter bashing occupied most of the meeting. In the context of that bashing, questions were asked. Some issues were raised, and the charter was amended.

Some of the main points that were brought up:

* The working group should focus on producing two major documents:

- A requirements document
- A resolution prtocol document

"Discovery" (finding an appropriate common name server) is an interesting but difficult problem. It is a practical problem that need to be solved in order to spread the use of common names, this problem should not be solved by the WG initially.

* Issues about schemas that are field specific.
The group thought that the protocol may try to focus on a minimal vocabulary. This minimal vocabulary would provide interoperability across resoultion services. However, the protocol should be extensible to support specialized schemas in the future.

* Authentication and privacy:
This is important to add to the charter. More specifically, this is a must-have for namespaces that will want to implement a business model where access is paid-for. On the other hand, fine-grained access control may not be a goal for many services with public information.

* Name ownership, name uniqueness issues should be out scope.

* Quality of service
Issues such as resolution response time should be considered as part of the goals.

* Usage scenarios
The goals document should contain some usage scenarios. This will help flesh out the real issues. Keith Moore suggested that considering business models as part of the scenarios is important, to make sure that the issues are well understood.

* Search versus resolution
A few people could not see the difference between search and common name resolution. They are quite dissimilar but since there is confusion, the distinction needs to be made clear in the charter

* Query interface:
Questions were raised about the kind of querues that could be addressed to a common name resolution service. It was said that the query interface should be kept simple. No Boolean query, no relevance ranking. This should be expressed in the modified charter as well.

* Speech interface
Someone asked for the protocol to support voice inputs Michael Mealling replied that this was mainly a UI issue. Voice could be one form of input. It would just be transformed into a string in a layer sitting above the resolution protocol. This lead the group to scope the problem to character/script input.


None received.