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.