Re: [urn] gbs Name space identifier

[Philip R Brenan <[e-mail]>]

Hi *Dale*:

In the latest version (attached) I have adopted your suggestion that the
definition of the <B> component should not be restricted to lowercase.
Instead
the <B> component is defined, as you suggested, in a manner that makes it
case
insensitive. I have added a recommendation that the <B> component be
presented
to humans in lowercase where possible as I believe that this makes the <B>
component less intimidating and thus more acceptable to people who are
working
on topics named using the proposed standard.  The relevant text now reads:

   <B> is the MD5 sum https://en.wikipedia.org/wiki/MD5 of the content being
   identified presented as a 32 character hexadecimal string represented by
   characters drawn from:

     a-fA-F0-9

   with uppercase and lowercase versions of a character being considered
   equivalent.

   Where possible, the <B> component should be presented to humans in
lowercase
   as operational experience indicates that this makes it easier for humans
to
   both locate and ignore the <B> component and concentrate instead on the
<G>
   component, which is usually much easier for humans to remember, say out
aloud
   and thus reason about than the <B> component.

And again, under Inter-operability:

   For many computations, the case of the letters in the URN is immaterial
and
   can be safely ignored  because only the <B> component is authoritative:
   although the preferred presentation of the <B> component is in lowercase
to
   minimize its visual impact on human readers, the <B> component may be
   represented using letters of either case.

Please let me now if you have other suggestions which would enable me to
refine
this proposal further?

On Thu, Oct 17, 2019 at 2:59 AM Dale R. Worley <[e-mail]> wrote:

> I see the new version as an enormous improvement.  One aspect that
> you've made clear is that for any given <B> value, there can be only one
> <G> value (although you cannot compute <G> from <B> unless you happen to
> have a copy of the topic to hand).
>
> As has been noted, URNs are *names* while URLs are *locators*, and URNs
> do not require a resolution process to locate the named resource.
>
> However, I think there are some aspects of the exposition that should be
> improved:
>
> Under "Resolution", it says:
>
>     Equivalence is determined by comparing (ignoring case) the <B>
> components
>     of the two topics to be compared.  If they are equal the two topics are
>     considered to be equal. Otherwise they are considered to be unequal
> even if
>     the underlying content is in fact identical. The characteristics of
> the MD5
>     sum ensure that only a small number of topics will be unnecessarily
>     duplicated as a result of such false positive equivalences.
>
> I do not see how "the underlying content is in fact identical" without
> generating the same <G> and <B>.  I suspect you mean that there can be
> two topics that have no *meaningful* difference but nonetheless have
> different <B> or <G>.
>
> Under "Security and Privacy", it says:
>
>    The validity of the URN can be checked as follows:
>
> However, these actions can only be done if one possesses not just the
> URN but also the content it refers to.  Usually "validity checking"
> names a procedure that only requires the URN as input.  So it would help
> if you expanded this sentence.  Perhaps, "The validity of the URN for a
> topic can be checked as follows:"
>
> Under "Inter-operability", it says:
>
>    The case of the letters chosen is immaterial and can be safely ignored
> in
>    all computations on the proposed URN as only the <B> component is used
> for
>    comparisons.
>
> The case of letters can be ignored for comparing URNs, but when copying
> or transmitting URNs, case has to be preserved, because only lower-case
> letters are valid in the <B> part of the URN, and the case of the
> letters in the <G> part must match that of the text from which it was
> derived -- so if you send the URN to another process, you have to get
> the case right.  So you want to narrow this statement.  Perhaps, "For
> many computations, the case of the letters in the URN is immaterial and
> can be safely ignored..."
>
> Dale
>


-- 
Thanks,

Phil <https://opentokrtc.com/room/phil>

Philip R Brenan <https://opentokrtc.com/room/phil>