[Uri-review] draft-paskin-doi-uri-03.txt [Response to Larry Masinter]

["Hammond, Tony (ELSLON)" <[e-mail]>]

Larry:

Thanks again for your additional comments. We try to address each in turn
below.

(BTW - Note that your original message of May 16 is fractured into two
pieces in the archive - with the penultimate para missing:

	
https://www1.ietf.org/mail-archive/working-groups/uri-review/current/maillis
t.html

The complete text of your post is anyway copied in this reply.)

Tony & Eamonn


=====

#1 - CNRP. We are not clear what relevance the CNRP work has for DOI.
Further, we have no information as to which bodies expressed this 'serious
concern' or if that concern has been subsequently integrated into any IETF
policy documents. We also do not understand what you intend by the following
phrase: '"yet another DNS": yet another system with a (controversial)
for-fee mechanism'. How does that relate to the 'tel' scheme for example? We
would certainly appreciate not being billed for line rentals or call
charges, but the telcos have a different POV.:)

(Incidentally, and on a separate thread, we don't see how the 'go' URI
scheme conforms to the BNF established in RFC 2396. Specifically the 'form1'
production does not appear to meet the 'net_path' production in RFC 2396
where the authority component is followed by an 'abs_path' production which
begins with a '/' character.)

#2 - E.164. The ITU document E.164 is 'The international public
telecommunication numbering plan' which explains the relationship between
E.164 strings and local dial strings. Similarly US standard ANSI/NISO
Z39.84-2000 formalizes the syntax for DOI strings.

It should also be pointed out that making a telephone call is not always as
straightforward as we might always imagine it to be. Often subscribers have
difficulty in making international calls, while at other times they may have
to negotiate a PBX's rules in order to secure an external line. (This of
course only relates to the 'tel' URI scheme. The 'fax' and 'modem' schemes
may be more difficult still to navigate.)

We note in passing that DOI is a well established identifier in use on the
Internet since 1997 - almost half the lifetime of the Web. It is an evolving
system and we have hitherto deferred registering a URI scheme until it had
achieved a critical mass in terms of the maturity of a consolidated market
penetration. DOI has no single resolution mechanism, but a default proxy
which is widely in use is available though the 'http://dx.doi.org/' service.

#3 - Protocol. The 'doi' scheme does not have a particular protocol
associated with it. The 'doi' scheme can be dereferenced through proxy
services (such as that available at http://dx.doi.org/). The 'doi' URI
scheme proposed is fully conformant to RFC 2396 which standardizes the
generic syntax for URI.

#4 - URN. You say that 'every URN scheme has a purpose beyond the purpose of
"urn" in general'. Would that not suggest that all new URI schemes should be
created under 'urn'? For as TimBL has noted, persistence is merely a social
issue. We don't understand this desire to limit the number of toplevel
schemes. RFC 2718 says:
	
	"URL schemes should have demonstrated utility.  New URL schemes are
      expensive things to support.  Often they require special code in
      browsers, proxies, and/or servers."

But surely this could equally well be applied to new URN Namespace IDs?

#5 - Syntax. Section 3 of the draft does indeed repeat productions from RFC
2396. The purpose is twofold: a) to provide those productions inline within
the document for easy access by the reader, and b) for fullest compliancy we
reuse the RFC 2396 productions. (We note that the 'go' URI scheme references
RFC 2396 productions - but as noted above there appears to be a mismatch
between the two BNFs.)

The DOI syntax for the schem-specific-part is conformant to an 'opaque_part'
production as indicated by the lack of a leading '/' character. No hierarchy
is therefore to be construed from the presence of the '/' character. (An
historical hierarchical relationship does exist between the 'prefix' and
'suffix' components at time of minting the identifier. Once created however
the identifier should be regarded as an opaque string. The only
interpretation that can be placed upon the 'prefix' string in a minted
identifier is that of the naming authority for creating new identifiers
under that namespace. The 'prefix' says nothing about the current ownership
of a particular identifier.)

#6 - Google. It strikes us as rather strange that an assessment of the
deployment of DOI is sought, though we have attempted to volunteer such
assessments (i.e. we provide an assessment in the draft and reference the
IDF website as an authority for further information). Assessments continue
to be posted and widely represented in press articles, newsgroups, etc.
Here's the March '03 DOI News posted on the LibLicense reflector:

	
http://www.library.yale.edu/~llicense/ListArchives/0303/msg00008.html

We note also that many existing URI schemes were registered without
demonstrable deployments. Indeed RFC 1630 is quite candid about this:

	"The following schemes ['mid', 'cid'] are proposed as essential to
the unification of
   the web with electronic mail, but not currently (to the author's
   knowledge) implemented"

Again other framework schemes such as 'data', 'go', etc may not have had any
widely installed base at time of registration. DOI has been in active use
since 1997 (about half the life of the Web), has an installed base of some
10m examples, and continues to grow both in numbers and in outreach to new
communities. In Google terms DOI represnts 0.325% usage compared Google's
indexed documents. (Of course, Google only indexes the surface Web and not
the so-called deep Web, yet it does represent a significant number of
deployed - and maintained - identifiers.)

#7 - Integrity. The IDF is a not-for-profit organization as laid out in its
charter. Fees levied on Registration Agencies are on a cost-recovery basis
and are for infrastructure funding and reliable operation of the resolution
mechanism. It is up to the Registration Agencies whether they choose to pass
these fees on to the Prefix Holders.

#8 - Newsgroup. To comment further on this topic we would require some
sources for this assertion - 'the newsgroup discussion' is far too vague -
Which newsgroup? What period? Which posts?

It is true that when the DOI was first launched some of the reporting may
have been a little enthusiastic and it may have appeared that there were
differences between publisher and librarian perspectives. However, with the
maturing of the DOI System, there is general agreement that DOI successfully
addresses the need to identify IPR entities on the Inernet.

You might like to note that current IDF members include the British Library,
Die Deutsche Bibliothek, Koninklijke Bibliotheek, OCLC Online Computer
Library Center Inc.
 
We would like to correct one detail. DOI is not a 'document identifier',
i.e. it is not just an asset management tool. It is a generic identifier for
entities of significance to the IPR communities. Such entities include
abstract works, manifestations, performances, parties and transactions.

#9 - Disclosure. Were such disclosures solicited from the various PSTN
communication carriers in respect of the 'tel, 'fax', 'modem' submission
(RFC 2806)?

We note that the DOI Registration Agencies (CrossRef is a good example) do
more that just register DOIs. They offer value added services and that is
what is invoiced. They are membership-based organizations whose members
voluntarily sign up to membership because it provides a valuable set of
services. Registration Agencies are free to operate any business model for
their members as they see fit.


We hope these points meet some of your concerns.

=====

> -----Original Message-----
> From: Larry Masinter [mailto:[e-mail]]
> Sent: 16 May 2003 20:32
> To: 'Hammond, Tony (ELSLON)'
> Cc: [e-mail]; [e-mail]
> Subject: RE: [Uri-review] Fwd: Re: Informational RFC to be:
> draft-paskin-doi-uri-03.txt (updated from -02.txt)
> 
> 
> Some background:
> 
> When the work on the "Common Name Resolution Protocol" was
> begun, there was serious concern about the IETF endorsing
> a mechanism that would wind up with "yet another DNS": yet
> another system with a (controversial) for-fee mechanism
> which charged an annual fee for assignment of names.
> Quite a bit of work went into the development of RFC 2972
> (which described the likely business models for naming
> authorities and resolution services) before the protocol
> (RFC 3367) and the URI scheme (RFC 3368) could be published.
> That experience suggests that there is some sensitivity
> around these issues, and that clear disclosure of policies
> and processes is expected.
> 
> Secondly, with regard to 'tel' and 'fax' as precedents:
> RFC 2806 maps the URI to a well-defined standard (E.164),
> and explains the relationship between the E.164 strings and
> local dial strings; how to dial a telephone number is
> widely understood. The 'doi' document, which cites 'tel'
> and 'fax' as a precedent, doesn't meet their level of
> specification.
> 
> > Is it now to be suggested that new candidate URI schemes must 
> > be tightly bound to an Internet protocol?
> 
> I think the candidate URI schemes must pass judgment as to
> whether they're well-enough defined. I think the definition needs
> to be in, or referenced by, the document that registers it.
> There might be some legacy cases where the definition is weak,
> but we should fix those. For some URIs, there's no resolution
> service at all (such as with cid or mid or uuid) but only
> a promise of uniqueness. But if you're going to promise
> resolution, then the resolution needs to be defined.
> 
> In the case of DOI, there seems to be some promise
> of a resolution services ("appropriate") without any
> definition of what it is, who might run it, etc.
> 
> > We also note that the functional requirements for URNs (RFC 
> 1737) do not
> > coincide with those of DOI, e.g. URN encoding. Furthermore, 
> URN syntax
> > places additional restrictive syntactic constraints on "doi" URIs.
> 
> I didn't see anything in the Internet Draft
> about functional requirements for DOIs that would lead one
> to conclude that the URN syntactic constraints are
> unacceptable. 
> 
>      RFC 2396 states that a "URN differs from a URL in that 
> it's [sic] 
>      primary purpose is persistent labeling of a resource with an 
>      identifier". A DOI on the other hand has a dual purpose: both to 
>      provide for the persistent identification of an entity of 
>      significance to the intellectual property communities, 
> as well as 
>      to enable access to a set of network services.
> 
> But every URN scheme has a purpose beyond the purpose of "urn"
> in general--else why a new scheme at all? The argument is
> illogical.
> 
> 
> Section 3 of draft-paskin-doi-uri-03.txt seems to repeat
> much of RFC 2396 BNF for no clear reason. The DOI syntax
> seems to use "/" for a non-hierarchical purpose, which seems
> to counter the general recommendations for URI syntax.
> 
> > #4 - Google. It should be pointed out that Google is 
> primarily a harvester
> > of documents referenced by "http" URI. Further, and more 
> importantly only
> > open sites are typically crawlable by robots. Subscription 
> sites offering
> > high value content are generally not indexable through 
> search engines like
> > Google.
> 
> > To support the contention that DOI is a well-established 
> identifier in an
> > active and deployed system the I-D referenced the DOI 
> website for further
> > information. As a simple indication of current usage, 
> however, you might
> > like to review last month's newsletter from CrossRef - a leading DOI
> > Registration Agent:
> > 
> > 	http://www.crossref.org/01company/10newsletter.html#eodiu
> > 
> > 	"Total Records in System: 7,458,490 (6,644,724 in January)"
> 
> I wasn't taking Google as a sole authority; I was looking for
> an independent ("without a beneficiary relationship") assessment
> of the deployment of DOIs.
> 
> > #6 - Patent/Trademark. First it should be pointed out that 
> there is no
> > patent issued for DOI. Second, the intention in registering 
> a trademark
> was
> > purely to secure the integrity of the DOI system. This 
> matter, however,
> > would be best addressed by the IDF.
> 
> I think the word 'integrity' can be taken several different ways.
> The integrity of a fee-collecting organization can only be secured
> if it continues to have an exclusive right to collect fees. And
> I don't really want to judge the intent, just the operational state.
> 
> While RFC 2026 section 10 only requires identification of intellectual
> property rights in standards-track documents, it would seem to me
> to be part of the judgment even for an 'informational' document
> that registers a URI scheme to disclose something that is not 
> otherwise
> well-known.
> 
> From what I can see in the newsgroup discussion in
> the library community, the use of DOI as a permanent
> document identifier is considered, at least by some,
> to be controversial, exactly because of the issues
> of control, authority, collection of fees, and so forth.
> 
> Given the discussion in
> http://www.crossref.org/01company/10newsletter.html#gi
> of invoices, non-linking fees, etc., I think additional
> disclosure is warranted, and that publication without
> disclosure would be a bad precedent for the IETF.
> 
> Larry
> 
> 
> 
> 
> 
> 
_______________________________________________
Uri-review mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/uri-review