Editor's Note:  These minutes have not been edited.


		  Minutes of the URN Working Group
			38th IETF Memphis TN
			April 10, 1997

Session Chair - Leslie Daigle, Bunyip
Minutes: Sally Hambridge - Intel


Summary:


The URN Working Group met and discuessed the status of submitted RFCs 
and drafts.  There are 3 documents which have gone to the IESG: The
URN Syntax draft as proposed standard, The NAPTR document, which has
gone as experimental, and the THTTP draft, also experimental.  There
are also 3 new drafts and one revised draft, although one "draft"
did not make it to the ID editor by the deadline for the Memphis meeting.
After discussing all the documents, the group reviewed progress to date
on milestones and agreed to a revised set of dates for deliverables.
Finally, they agreed to creating a FAQ to document decisions, and
to using the RFCs as a new namespace (pending IESG approval).


Minutes:

Leslie opened the meeting by reviewing the status of the charter.  We
have not met all the milestones although we have made substantial progress.
The group has 3 documents which have gone to the IESG:  The URN Syntax
has gone as a proposed standard, the NAPTR document has gone as an 
experimental document, and the THTTP document has also gone as an
experimental document.  The group has 3 new drafts and one revised draft.
There are relatively few things left as milestones which we have to
produce so it is conceivable that Munich might be our last meeting.

Karen Sollins presented the Framework and Requirements Document and
began by talking about the Security requirements.  She has added some
paragraphs on potential threats and how to deal with them in the
framework (not mechanisms to deal with them).  She noted that there
was clarification needed about the words "authoritative" which could
mean it must be possible to have a version by a person authorized to 
write it, or there must be a certified version.  Both should be 
possible.  She also noted that "access control" could mean access for
read only, for read and modify, and for read with verification.  There
also needs to be a means for certification without passing the original
record.

Leslie then wondered if the draft should really be called a "Requirements"
document when we would not be able to see far enough into the future to
be able to state categorically what needed to be a requirement.  John
Curran thought the draft was much better than previous versions as one
could easily relate paragraphs to requirements, but he too felt uneasy
with the word "requirements".  After much discussion, we agreed (ROUGH
CONSENSUS - FAQ maintainer take note) that the Document should proceed
but needed to be called Guidelines or Considerations for an RDS rather
than Requirements.  Karen felt that ubiquity and scalibility were
requirements (or considerations) which were still missing from the 
document, and urged us to take up discussion of these issues on the
list.

John Curran said that in the future, after we have operational experience
we (not in the lifespan of this working group) needed to produce a crisp 
requirements document and that Karen's doc would continue to proceed as 
informational.

Michael Mealling spoke to the URN Resolution Services draft.  He
said he had drawn most of the content from the THTTP draft.  He felt
that the scope of the document was larger than the working group 
charter, since it encompassed other URI services.  Karen suggested
he needed to be clearer that he was not talking about a global RDS
but about local resolution services.  The draft also needs a section
on security considerations, and on error processing.  John C. pointed
out that Text/URI was not registered as yet, and Ron Daniel admited 
he needed to do that.  Karen S said she was not happy with the example
and that we needed to be clearer about "today's weather" and " a weather
map for April 10, 1997" which were 2 separate things which might have
a point in time of overlap and Michael agreed that a concept of equality
which is time-based needs to be clarified.

Finally, we agreed (ROUGH CONSENSUS) that the draft needed to be called 
URI Services necessary for URN Resolution services and that it could
proceed as either informational or experimental.  Again, a standards-track
document will be revisited after operational experience has been gained.

Cliff Lynch presented the ID which is not quite an ID.  It had been
posted to the list, but in a format that was not friendly for all
mailers and needed to be re-posted.  Since the URN syntax has been 
established, this draft explored how ISBNs and ISSNs as well as 
Serial Item and Contribution Identifier Strings might map to URN.  There 
are no particular syntax problems although some %HH encoding is required.
This document is useful for showing how resolution will work in practice.
ISSNs will probably take the user to a navigation apparatus because
they represent an ongoing publication,  The apparatus will lead the
user to a way to search/browse the serial desired.  The group made clear
that this document showed how the bibliographic area mapped into the
URN name space.  Ron pointed out a caveat that we hadn't talked about
which standards bodies have control over the ISBN and ISSN space and
Cliff assured him there was weasel language in the draft over this issue.

Patrik Faltstrom presented the Namespace Requirements draft.  This draft is 
problematic because in trying to define the requirements for registering
of a name space one fell into operational requirements for the registration
process.  There has been some violent disagreement about what
should be in the document, and Patrik and his co-author Renato (not able
to be present at the meeting), did not even seem to be in agreement.  Patrik 
thought it should deal with grandfathering in existing name spaces.  Renato 
thought it should be about the registration process.  John C. suggested we 
decide who the consumer of the document should be.  He suggested we presume 
it was IANA, and that we should think about what IANA would need from the 
document.  We decided (ROUGH CONSENSUS) that the document needed to go 
forward as a non-judgemental checklist.  This lead to a discussion about
the problems of having a checklist which avoided operations issues,
and the problems of assigning names.  Michael Mealling mentioned that
he needed some arbiter for this problem, and Leslie suggested he refer
current name registration problems to the URN WG.  Leslie acknowledged that we 
have problems with assigning name spaces: Is it a name space, Should 
someone have the name?  What happens when "you" say "no"?  We are just
NOT ready to address the "Can you have it" problem, and will focus
for now on the technical issues of evaluation whether something COULD be a 
namespace.

We spoke for quite a while on the problems of registering name spaces
and discovered areas where there be dragons.  There seems to be large
dragons where ownership is unclear.

To Summarize for existing drafts:

Requirements and Framework - will go through another round of editing, and
continue on its way as informational with a change in focus from 
"requirements" to "Considerations and Guidelines".

URN Resolution Services: Will go forward as FYI as the "List of URI
Services needed by URNS"

Bibliographic IDs - is OK as a proof of the concept.  Will go quickly
to last call  as informational after reposting to the list in a 
format readable by all.

Namespace Requirements - Will describe technical considerations of 
a namespace - not "Can you have it" issues.

We decided we needed a glossary which would define terms which spanned
all the documents.  Dirk-Willem Van Gulik volunteered to be the
glossary editor, and thought he could have a version which would be
put on the web-page by July 1997.

Other Issues

Ryan Moats presented an Experimental URN namespace, in which he 
took RFC's as the data.  The experiment is intended to help gain
experience and insight into the namespace registration process and
issues.

NID: "ietf"
BNF grammar for NSS:
 - <nss> := <family> ":" <number>
 - <family> := "rfc" | "std" | "fyi"
 - <number> := sequence number

Resolution functionality is currently: N2L, N2Ls, N2R, N2Rs, N2C

Introductory URL Page: http://dsm0.ds.internic.net/urn

URL for testing:
http://dsm0.ds.internic.net:8080/urn-res/<function>>?<urn>

Michael said he will try NAPTR today as well.

Following on to Dan Connolly's suggestion on the mailing list, the group then 
decided that decisions of the group needed to be captured somehow, so we did 
not have to contantly revisit decisions.  We decided (ROUCH CONSENSUS) to 
create a FAQ which could be posted to the list periodically.  Leslie will 
write the first iteration of the FAQ.  One of the first things to be 
documented will be the decision surrounding the use of urn:

There is a new URL syntax draft (draft-*-fielding---.04.txt) which has
ONE paragraph which says that URL syntax is for all URIs.  We will
approach the editors and ask them to change it.  We need to demonstrate
the lack of consensus from the URN working group that the URL
syntax draft applied to URNs.  There is very good work in the draft 
about relative URLs.  

We then reviewed the milestones and decided that the only work which was
absent was work on a new namespace.  We elected to use Ryan Moats 
experiment with the RFCs pending approval from the IESG.  The new 
milestones are:

May 97
     Submit revised grandfather namespace document as Internet-Draft.
May 97
     Submit revised N2L/N2R/etc document as an Internet-Draft.
May 97
     Submit revised namespace requirements document as an Internet-Draft.
May 97
     Submit document describing one (new) namespace as an Internet-Draft.
May 97
     Submit Framework (Guidelines) document to IESG for publication as an RFC. 
Jul 97
     Submit N2L/N2R/etc document to IESG for publication as RFC.
Jul 97
     Submit grandfathered namespace paper to IESG for publication as RFC.
Jul 97
     Submit revised new Namespace document as Internet-Draft.
Aug 97
     Submit new namespace proposal to IESG for publication as RFC

The meeting ended on time.





----------------------------------------------------------------------------

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              leslie@bunyip.com
----------------------------------------------------------------------------