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 >
Text File  |  1997-05-29  |  11KB  |  224 lines

  1. Editor's Note:  These minutes have not been edited.
  2.  
  3.  
  4.           Minutes of the URN Working Group
  5.             38th IETF Memphis TN
  6.             April 10, 1997
  7.  
  8. Session Chair - Leslie Daigle, Bunyip
  9. Minutes: Sally Hambridge - Intel
  10.  
  11.  
  12. Summary:
  13.  
  14.  
  15. The URN Working Group met and discuessed the status of submitted RFCs 
  16. and drafts.  There are 3 documents which have gone to the IESG: The
  17. URN Syntax draft as proposed standard, The NAPTR document, which has
  18. gone as experimental, and the THTTP draft, also experimental.  There
  19. are also 3 new drafts and one revised draft, although one "draft"
  20. did not make it to the ID editor by the deadline for the Memphis meeting.
  21. After discussing all the documents, the group reviewed progress to date
  22. on milestones and agreed to a revised set of dates for deliverables.
  23. Finally, they agreed to creating a FAQ to document decisions, and
  24. to using the RFCs as a new namespace (pending IESG approval).
  25.  
  26.  
  27. Minutes:
  28.  
  29. Leslie opened the meeting by reviewing the status of the charter.  We
  30. have not met all the milestones although we have made substantial progress.
  31. The group has 3 documents which have gone to the IESG:  The URN Syntax
  32. has gone as a proposed standard, the NAPTR document has gone as an 
  33. experimental document, and the THTTP document has also gone as an
  34. experimental document.  The group has 3 new drafts and one revised draft.
  35. There are relatively few things left as milestones which we have to
  36. produce so it is conceivable that Munich might be our last meeting.
  37.  
  38. Karen Sollins presented the Framework and Requirements Document and
  39. began by talking about the Security requirements.  She has added some
  40. paragraphs on potential threats and how to deal with them in the
  41. framework (not mechanisms to deal with them).  She noted that there
  42. was clarification needed about the words "authoritative" which could
  43. mean it must be possible to have a version by a person authorized to 
  44. write it, or there must be a certified version.  Both should be 
  45. possible.  She also noted that "access control" could mean access for
  46. read only, for read and modify, and for read with verification.  There
  47. also needs to be a means for certification without passing the original
  48. record.
  49.  
  50. Leslie then wondered if the draft should really be called a "Requirements"
  51. document when we would not be able to see far enough into the future to
  52. be able to state categorically what needed to be a requirement.  John
  53. Curran thought the draft was much better than previous versions as one
  54. could easily relate paragraphs to requirements, but he too felt uneasy
  55. with the word "requirements".  After much discussion, we agreed (ROUGH
  56. CONSENSUS - FAQ maintainer take note) that the Document should proceed
  57. but needed to be called Guidelines or Considerations for an RDS rather
  58. than Requirements.  Karen felt that ubiquity and scalibility were
  59. requirements (or considerations) which were still missing from the 
  60. document, and urged us to take up discussion of these issues on the
  61. list.
  62.  
  63. John Curran said that in the future, after we have operational experience
  64. we (not in the lifespan of this working group) needed to produce a crisp 
  65. requirements document and that Karen's doc would continue to proceed as 
  66. informational.
  67.  
  68. Michael Mealling spoke to the URN Resolution Services draft.  He
  69. said he had drawn most of the content from the THTTP draft.  He felt
  70. that the scope of the document was larger than the working group 
  71. charter, since it encompassed other URI services.  Karen suggested
  72. he needed to be clearer that he was not talking about a global RDS
  73. but about local resolution services.  The draft also needs a section
  74. on security considerations, and on error processing.  John C. pointed
  75. out that Text/URI was not registered as yet, and Ron Daniel admited 
  76. he needed to do that.  Karen S said she was not happy with the example
  77. and that we needed to be clearer about "today's weather" and " a weather
  78. map for April 10, 1997" which were 2 separate things which might have
  79. a point in time of overlap and Michael agreed that a concept of equality
  80. which is time-based needs to be clarified.
  81.  
  82. Finally, we agreed (ROUGH CONSENSUS) that the draft needed to be called 
  83. URI Services necessary for URN Resolution services and that it could
  84. proceed as either informational or experimental.  Again, a standards-track
  85. document will be revisited after operational experience has been gained.
  86.  
  87. Cliff Lynch presented the ID which is not quite an ID.  It had been
  88. posted to the list, but in a format that was not friendly for all
  89. mailers and needed to be re-posted.  Since the URN syntax has been 
  90. established, this draft explored how ISBNs and ISSNs as well as 
  91. Serial Item and Contribution Identifier Strings might map to URN.  There 
  92. are no particular syntax problems although some %HH encoding is required.
  93. This document is useful for showing how resolution will work in practice.
  94. ISSNs will probably take the user to a navigation apparatus because
  95. they represent an ongoing publication,  The apparatus will lead the
  96. user to a way to search/browse the serial desired.  The group made clear
  97. that this document showed how the bibliographic area mapped into the
  98. URN name space.  Ron pointed out a caveat that we hadn't talked about
  99. which standards bodies have control over the ISBN and ISSN space and
  100. Cliff assured him there was weasel language in the draft over this issue.
  101.  
  102. Patrik Faltstrom presented the Namespace Requirements draft.  This draft is 
  103. problematic because in trying to define the requirements for registering
  104. of a name space one fell into operational requirements for the registration
  105. process.  There has been some violent disagreement about what
  106. should be in the document, and Patrik and his co-author Renato (not able
  107. to be present at the meeting), did not even seem to be in agreement.  Patrik 
  108. thought it should deal with grandfathering in existing name spaces.  Renato 
  109. thought it should be about the registration process.  John C. suggested we 
  110. decide who the consumer of the document should be.  He suggested we presume 
  111. it was IANA, and that we should think about what IANA would need from the 
  112. document.  We decided (ROUGH CONSENSUS) that the document needed to go 
  113. forward as a non-judgemental checklist.  This lead to a discussion about
  114. the problems of having a checklist which avoided operations issues,
  115. and the problems of assigning names.  Michael Mealling mentioned that
  116. he needed some arbiter for this problem, and Leslie suggested he refer
  117. current name registration problems to the URN WG.  Leslie acknowledged that we 
  118. have problems with assigning name spaces: Is it a name space, Should 
  119. someone have the name?  What happens when "you" say "no"?  We are just
  120. NOT ready to address the "Can you have it" problem, and will focus
  121. for now on the technical issues of evaluation whether something COULD be a 
  122. namespace.
  123.  
  124. We spoke for quite a while on the problems of registering name spaces
  125. and discovered areas where there be dragons.  There seems to be large
  126. dragons where ownership is unclear.
  127.  
  128. To Summarize for existing drafts:
  129.  
  130. Requirements and Framework - will go through another round of editing, and
  131. continue on its way as informational with a change in focus from 
  132. "requirements" to "Considerations and Guidelines".
  133.  
  134. URN Resolution Services: Will go forward as FYI as the "List of URI
  135. Services needed by URNS"
  136.  
  137. Bibliographic IDs - is OK as a proof of the concept.  Will go quickly
  138. to last call  as informational after reposting to the list in a 
  139. format readable by all.
  140.  
  141. Namespace Requirements - Will describe technical considerations of 
  142. a namespace - not "Can you have it" issues.
  143.  
  144. We decided we needed a glossary which would define terms which spanned
  145. all the documents.  Dirk-Willem Van Gulik volunteered to be the
  146. glossary editor, and thought he could have a version which would be
  147. put on the web-page by July 1997.
  148.  
  149. Other Issues
  150.  
  151. Ryan Moats presented an Experimental URN namespace, in which he 
  152. took RFC's as the data.  The experiment is intended to help gain
  153. experience and insight into the namespace registration process and
  154. issues.
  155.  
  156. NID: "ietf"
  157. BNF grammar for NSS:
  158.  - <nss> := <family> ":" <number>
  159.  - <family> := "rfc" | "std" | "fyi"
  160.  - <number> := sequence number
  161.  
  162. Resolution functionality is currently: N2L, N2Ls, N2R, N2Rs, N2C
  163.  
  164. Introductory URL Page: http://dsm0.ds.internic.net/urn
  165.  
  166. URL for testing:
  167. http://dsm0.ds.internic.net:8080/urn-res/<function>>?<urn>
  168.  
  169. Michael said he will try NAPTR today as well.
  170.  
  171. Following on to Dan Connolly's suggestion on the mailing list, the group then 
  172. decided that decisions of the group needed to be captured somehow, so we did 
  173. not have to contantly revisit decisions.  We decided (ROUCH CONSENSUS) to 
  174. create a FAQ which could be posted to the list periodically.  Leslie will 
  175. write the first iteration of the FAQ.  One of the first things to be 
  176. documented will be the decision surrounding the use of urn:
  177.  
  178. There is a new URL syntax draft (draft-*-fielding---.04.txt) which has
  179. ONE paragraph which says that URL syntax is for all URIs.  We will
  180. approach the editors and ask them to change it.  We need to demonstrate
  181. the lack of consensus from the URN working group that the URL
  182. syntax draft applied to URNs.  There is very good work in the draft 
  183. about relative URLs.  
  184.  
  185. We then reviewed the milestones and decided that the only work which was
  186. absent was work on a new namespace.  We elected to use Ryan Moats 
  187. experiment with the RFCs pending approval from the IESG.  The new 
  188. milestones are:
  189.  
  190. May 97
  191.      Submit revised grandfather namespace document as Internet-Draft.
  192. May 97
  193.      Submit revised N2L/N2R/etc document as an Internet-Draft.
  194. May 97
  195.      Submit revised namespace requirements document as an Internet-Draft.
  196. May 97
  197.      Submit document describing one (new) namespace as an Internet-Draft.
  198. May 97
  199.      Submit Framework (Guidelines) document to IESG for publication as an RFC. 
  200. Jul 97
  201.      Submit N2L/N2R/etc document to IESG for publication as RFC.
  202. Jul 97
  203.      Submit grandfathered namespace paper to IESG for publication as RFC.
  204. Jul 97
  205.      Submit revised new Namespace document as Internet-Draft.
  206. Aug 97
  207.      Submit new namespace proposal to IESG for publication as RFC
  208.  
  209. The meeting ended on time.
  210.  
  211.  
  212.  
  213.  
  214.  
  215. ----------------------------------------------------------------------------
  216.  
  217.   "_Be_                                           Leslie Daigle
  218.              where  you                           
  219.                           _are_."                 Bunyip Information Systems
  220.                                                   (514) 875-8611
  221.                       -- ThinkingCat              leslie@bunyip.com
  222. ----------------------------------------------------------------------------
  223.  
  224.