[Uri-review] draft-paskin-doi-uri-03.txt [Response to Martin Duerst]

Hi Martin:

Thanks for your comments. We have responded inline.

Tony & Eamonn

> >We also note that the functional requirements for URNs (RFC 
> 1737) do not
> >coincide with those of DOI, e.g. URN encoding.
> 
> re. character encoding, URN uses UTF-8. DOI uses UTF-8 (which is
> just the right thing to do, by the way!). So you are probably speaking
> about something else. Can you elaborate?

We will need to review this point.

> >Furthermore, URN syntax
> >places additional restrictive syntactic constraints on "doi" URIs.
> 
> What exactly? That you cannot use slashes? If you don't use them
> for hierarchy/relative URI processing, don't use them at all.

As noted in the response to Larry, DOI demonstrates an historical hierarchy
which is in evidence at time of creation only.

As for not using the '/' character, we do not understand why it is suggested
that a non-hierarchical URI should not make use of such characters. They are
reserved because in hierarchical URIs they have significance in separating
path components. In a non-hierarchical URI (one marked off by having no
leading '/' character) they are merely another uric character devoid of any
meaning.

> >We view registered URI schemes such as "tel", "fax", etc as 
> being valid and
> >see a useful precedent for a loose binding of URI scheme to Internet
> >protocol such as exhibited by DOI.
> 
> The problem is not the linking to an Internet protocol, it's that
> the definition of how to find out what a praticular doi: URI refers
> to.
> 

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/).

> - Please don't use the term 'lexical' equivalence.

Not clear why you want to avoid the term 'lexical' which has been used in
previous RFCs, but we can do that if required.

> - The update work on URIs focuses much more on 'start off with
>    the canonical form'. You should probably do that, too.
> - For the hex characters after the %-sign, the default is now
>    upper-case. For the scheme, it's lower case. For the rest,
>    it's your choice, lower case seems fine.

We can amend the wording along the lines that you suggest. Note also your
point about hex characters being capitals. Maybe we just need to add an
extra step to the matching algorithm.

> - Having a separate section for examples looks strange.
>    Please make that 4.1.
> - Give some more examples, so that
> - How is case equivalence handled for non-ASCII characters?

Sure - can do. Might also be useful to include an example of a DOI with
whitespace and suitably hex encode. 
_______________________________________________
Uri-review mailing list
Uri-review@ietf.org
https://www1.ietf.org/mailman/listinfo/uri-review