Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-minutes-96dec.txt

Text File | 1997-01-30 | 8KB | 192 lines

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


                   Minutes of the URN Working Group
                 37th IETF, San Jose, December 12, 1996

Group Co-Chairs: Leslie Daigle, [e-mail]
                 John Curran, [e-mail]

Minute-Meister:  Sally Hambridge,  Intel

Leslie opened the meeting by reviewing the Charter and Milestones.
Hot Spots in the milestones are: we lack a draft detailing
N2L/N2R/etc resolution results.  We will probably use Ron Daniel's HTTP
conventions draft as a start on this milestone.  We also need to
submit a document describing one new namespace and a document
which describes grandfathering in older naming schemes, as well
as the Frameworks and Requirements draft.

Karen Sollins presented the open issues with the current
Frameworks and Requirements document:

The document discusses the assumptions of longevity, delegation,
and independence.  The requirements fall in 3 major areas:
Evolution, Usability, and Security.  The framework looks like
this:

URN:<NID><NSS>
   |
   |
Global NID registry
  |        |
  |        |
  |     Private URN resolution service
UDS server
  |
  |
Private URN resolution service

Karen includes a definition section which defines Local
Resolution service - what transforms URNs into access to
resources; Hints - information that helps to access the
information; UDS - URN Resolution Service Discovery Service - how
to find the right URN resolution service; HFN - Human friendly
names.

The Security area will discuss access control on hints; server
authenticity; Server distribution (a countermeasure on denial of
service attacks) and Privacy - the users from resolution services
and for publishers for their clients and publications lists.

Issues:
    - Encouragement of separation of URNs from semantics
    - Efficiency as a goal or a requirement is in several places
      (documents) which need to be aggregated.
    - Whether there is a useful distinction to be made between long-
      term and short-term hints
    - Acceptance by potential providers of UDS services.

Karen asked what's missing from the list of issues:
Internationalization (i18n) should be covered one way or another.
Name space ID - needs to be in a document but probably not this
document.

Ryan Moats presented the issues with the URN syntax ID:

URN: should this be optional.  Please see the later discussion on
this for the consensus.

NID syntax: Why not use numbers and "-".  No reason - Ryan will
change the draft.  There was a suggestion for following the RFC
for URLs on this, but it was pointed out that this document is
currently undergoing a revision.  NID namespace will have case
insensitivity and add %escaping.  The NSS may be case sensitive.

URN Character set adds/deletes: Add "%" to the allowed character
set and add a list of characters NOT part of the set to the
draft.

%escaping: Will be allowed for escaping of reserved characters in
addition to characters outside the URN character set; and allow
for %HH escaping to use either upper or lower case.
Where does a URN end? At the first non-URN character set
character.

Equivalency: Are things the same when they point to the same
resource?  (Equivalency of resources was deemed to be a
rathole).    Leslie offered that a URN could point to a specific
day's weather and another could refer to today's weather, and
these were pointing to the same thing but were not equivalent.
ROUGH CONSENSUS was reached that ONLY lexical equivalency will be
covered in the draft.  Each namespace may have its own rules.

For the Human readability - MUST/SHOULD the following text is
being substituted:
  Any namespace (existing or newly-devised) that is proposed as a
  URN-namespace must be expressed in this syntax.  If names in
  these namespaces contain characters other than those defined for
  the URN character set they must be translated into canonical form
  as discussed in section 2.2

Ron Daniel discussed the NAPTR draft.

    - There will be verbiage to state that records with unknown
      flags must be ignored.
    - The Pseudo-code will get a strong disclaimer.
    - "R" Flag for treating Regex as "Raw"
    - Don't do "E" flag for encrypting Raw fields.
    - Flag field reserves 0-9 for experimentation. ROUGH CONSENSUS was to
      allow people to create new flags however they want, but that if
      you see a flag you don't recognize you ignore it. Ron is going to
      revise the wording of the draft so that people may place any
      interpretation they want on the various fields as long as they
      define a flag for it.

There was a question of the references to other drafts, and John
Curran said he would find out if the text RFC xxx could be
written and if the RFC editor would insert the correct numbers.

This draft will be going as an Experimental RFC.  There was
discussion about how the experimental status will effect DNS and
the regex substitutions.  We need to be explicit.  We need to
say how this doesn't overload DNS and how DNS security will help
and where it won't.  Also, there will probably be more than one
discover service in the future and we don't want this one to be
"The Standard".  We need operational experience.  The requiring
resolution problem is not part of this draft.  We will have one
more revision on the mailing list, then this goes to
Experimental.

HTTP Conventions: Ron took this one too.

We need a simple resolver for testing, the goal is not
Standards track.  The goal is to use the conventions on encoding
on requests and responses on http:

GET /uri-res/<server>/<uri> HTTP 1.0



Open Discussion:

URN:  There was a question of rough consensus on the problem of
whether to require urn:.  The room seems to indicate that urn:
should be required on any part of the urn that was shipped around
the Internet.  Whether or not implementors would use urn: was
left up to them for their own local products, but in transmission
the urn: would be required.  The problem with urn: seems to be at
the user interface and user services level.  Don't confuse human
friendly names with internal representation.

Documents:
We need a URN dereferencing document to discuss the resolution
service and the resolution system.  These need the syntax (which
is close) and the system requirements needs the framework (which
is also close.)

Assign URN - needs everything! We need namespace requirements.
Renato Iannella was volunteered to create a first draft of this
document.  We need to have one new namespace and we need to bring in 1
existing namespace.  We need to pay some attention to potential
lawsuit issue.  It is important for someone who has authority for
the namespace to say how it works in URN.  The proposal is for
these to be experimental.  Dun and Bradstreet is interested in
working on this as soon as the syntax is ready.  Clifford Lynch
said that the NISO bibliographic IDs could move en masse.

We can create a resolution system which can be used outside the
URN space, but we need to make it work there first.

Charter directions:

* We need to get a grip on bringing in an existing namespace
* We need a new namespace scheme
* We need the Name space requirements document (to see whether
DNS-based  namespace will or won't work, and if not, what we can
do about a generically-accessible namespace)
* We need to look at the process of creating new namespaces



--

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

  "_Be_                                           Leslie Daigle
             where  you                           Vice President, Research
                          _are_."                 Bunyip Information Systems
                                                  [phone]
                      -- ThinkingCat              [e-mail]
----------------------------------------------------------------------------