home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
urn
/
urn-minutes-97apr.txt
< prev
next >
Wrap
Text File
|
1997-05-29
|
11KB
|
224 lines
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
----------------------------------------------------------------------------