Subject: Re: [urn] gbs Name space identifier

From: "Hakala, Juha E" <[email-masked]>
Date: Wed, 2 Oct 2019 04:42:22 +0000

Hello Philip,

as far as I am concerned, the application does not require any further editing, except that you should remove the extra “h” from

hhttps://metacpan.org/pod/Dita::GB::Standard<http://metacpan.org/pod/Dita::GB::Standard>

IMO one of the main challenges with namespace registration requests has been that the authors themselves usually know well the intended scope the proposed namespace. Alas, it may be difficult to communicate this information to reviewers who might not be familiar with the context. The text below is now pretty good at explaining the initial usage of  urn:gbs identifiers.

I think it is a good idea that there is also room for growth. In ISO TC 46/SC 9 (which deals with ISO standard identifiers like ISSN, ISBN and DOI) we recently evaluated a new work item proposal for an identifier that would have been machine generated from the content of the identified textual resource like urn:gbs:dita’s. Alas, the proposed syntax and algorithms were not rigorous enough, and the proposal was not approved.

As an aside, in order to make urn:gbs:dita’s ISO standard identifiers, it would be necessary to standardize just RFC 8141 in ISO. Would you have any interest on elevating the status of urn:gbs like that? Since IETF is Category A liaison with ISO TC 46, fast track process could be used to create quickly an ISO standard which is identical with the original one.

All the best,

Juha

Lähettäjä: Philip R Brenan <[email-masked]>
Lähetetty: sunnuntai 29. syyskuuta 2019 16.57
Vastaanottaja: Hakala, Juha E <[email-masked]>
Kopio: [email-masked]; [email-masked]; Dale R. Worley <[email-masked]>
Aihe: Re: [urn] gbs Name space identifier

Hi Juha:

Thank you for your helpful comments.

I have updated this document based on the email discussion as follows:

1 - Clarified that the principle purpose of the URN being applied for is for
naming topics rather than locating them.

2 - Specified that currently there is only one <T> type active, namely "dita".

3 - Specified the computation of the <G> component in this document rather than
by reference elsewhere.

4 - Expanded the discussion of the purpose of the URN.

5 - Expanded the discussion on naming versus location and why naming is so
useful in this context.

6 - Expanded the discussion of inter-operability.

Please let me know which areas of this application might require further
elaboration?

Per: https://tools.ietf.org/html/rfc8141

Namespace ID:

   gbs

Registration Information:

   Version: 1
   Date:    2019-09-27

Declared registrant of the namespace:

   Name:    Ryffine Inc.
   Address: 445 N Broadway, Denver, CO 80203
   Contact: Philip R Brenan
   E-mail:  [email-masked]<mailto:[email-masked]>
   www:     http://www.ryffine.com

Purpose:

   To allow organizations to share content written in Xml to the Dita Standard:
   http://docs.oasis-open.org/dita/dita/v1.3/os/part2-tech-content/dita-v1.3-os-part2-tech-content.html
   without the exponential duplication that occurs without the name space
   standardization provided by a URN.

   Dita is a technical documentation standard promulgated by OASIS: a nonprofit
   consortium that drives the development, convergence and adoption of open
   standards for the global information society as noted at
   https://www.oasis-open.org/org

   A major goal of Dita is to enable authors to build documents from small
   reusable components called topics and then to share and reuse these topics
   via collections to enable other documents to be be built more rapidly.

   As a consequence of the current addressing mechanism used to link Dita
   topics together within a document the number of such topics in existence
   tends to grow exponentially over time as documents evolve.  Typically when a
   new version of a product is documented the author takes the existing set of
   linked topic files comprising the documentation of the product, duplicates
   all of these files to preserve the complex linkage structure between these
   topics, then makes a small number of changes to a few of the duplicated
   files, leaving the bulk of the topic files unchanged.  At the moment it is
   difficult to reuse the original topic files in situ because of the need to
   maintain the links between them.

   The GB Standard as currently implemented at:

   hhttps://metacpan.org/pod/Dita::GB::Standard<http://metacpan.org/pod/Dita::GB::Standard>

   seeks to reduce this exponential growth of topic files by giving each topic
   a unique deterministic name so that links between topics can be expressed in
   a way that endures as the topic files are copied over time.

   As proposed, the GB Standard allows a collection of Dita topics to quickly
   determine whether it already has a copy of an incoming topic by computing
   the GB Standard name of the topic and comparing it to the names of all such
   topics already collected locally ready for publication. If the name already
   exists then the incoming topic is discarded and the existing topic is
   reused, if the name does not exist in the collection then the collection
   adds the incoming topic to its list of topics available for publication.

   At the same time, the GB standard provides a human readable name for each
   topic which assists authors in selecting topics from each collection for
   reuse.

   The GB standard has been used by the applicant since 2016 to successfully
   build and maintain several large collections of topics.

   The purpose of this application then is to formalize the GB Standard naming
   convention as a globally recognized URN to enable standardized topic naming
   among organizations collaborating on the production of collections of
   technical documentation using Dita.  The proposed URN will not, as it
   stands, provide immediate global location of topics so named, instead, it
   provides a standardized method of querying one or more collections of such
   topics by both humans and computers in an efficient manner.

Syntax:

   urn: gbs : <T> : <G> : <B>

   where:

   <T> is a string of one or more characters drawn from: [a-zA-Z0-9_] which
   identifies the type of content being classified. At this point in time only
   one such type is in active use: the "dita" type. It is possible that further
   types might be required in the future, if so, this document will be updated
   to reflect these new types.

   <G> is a string of 1 to 64 characters drawn from: [a-zA-Z0-9_].  When <T>
   has the value: "dita" (currently the only permissible value),  <G> is
   computed by concatenating the text between which ever of the following Xml
   tags exist in a the Dita topic in the order in which they appear in that
   topic:

     <title>  <mainbooktitle>  <booktitlealt>

   The text between these tags is used to form the <G> component after
   converting runs of all characters other than a-zA-Z0-9 to single underscores
   and truncating after character 64 if the resulting string is longer than 64
   characters in length. This method was chosen based on operational experience
   as it produces readable names that are closely aligned with what authors
   expect to see as a topic name.

   <B> is the MD5 sum https://en.wikipedia.org/wiki/MD5 of the content being
   identified presented as a 32 character lowercase hexadecimal string drawn
   from: [a-z0-9]{32} . Presenting the MD5 sum in lowercase, last and therefore
   to the right has the beneficial side effect of allowing authors to visually
   ignore it and concentrate instead on the <G> component in the majority of
   cases where the <G> component happens to be (almost) unique.  This
   arrangement makes the GB Standard name useful to both humans and computers.

Assignment:

   Identifier uniqueness considerations:

       Uniqueness is guaranteed by the <B> component being an MD5 sum and is
       thus guaranteed to be identical for identical content and very probably
       different for differing content.

   Identifier persistence considerations:

       Persistence is guaranteed by the immutability over time of the MD5 sum
       of the <B> component.

   Process of identifier assignment:

       <T> is currently set to "dita".

       <G> is chosen algorithmically depending on the value of <T> using the
       topic as input as described above.

       <B> is chosen by computing the MD5 sum of the content.

  For example:

       urn:gbs:dita:Introduction_to_the_GB_Standard:dddb7e2c29d2c8b9d87187fdf52a2702

Resolution:

    Content cannot be directly located by this standard.  However, URN's are
    not necessarily required to provide locations services initially: providing
    a globally unique name is valuable in its own right because it encourages
    the development of, and convergence on, a small number of large, shared,
    inter-operable, global collections of topics within each of which the
    uniqueness of the URN is sufficient to provide a location service.

    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.

Security and Privacy:

   The validity of the URN can be checked as follows:

   Check that the <T> component is "dita".

   Check that the <G> component is computed correctly as described above.

   Check the the <B> component matches the MD5 sum of the content.

Inter-operability:

   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.

   Dita topics that do not contain ASCII characters suitable for constructing
   the <G> component will be accommodated by adding a new value to the list of
   values accepted by the <T> component and specifying the corresponding
   algorithm for computing the <G> component in an update to this document.

Additional Information:

   An implementation in Perl of the GB Standard as specified above  when <T> is
   equal to "dita" is located at:

   https://metacpan.org/pod/Dita::GB::Standard

References:

   ASCII: https://en.wikipedia.org/wiki/ASCII

   Dita specification: http://docs.oasis-open.org/dita/dita/v1.3/os/part2-tech-content/dita-v1.3-os-part2-tech-content.html

   MD5 Sum: https://en.wikipedia.org/wiki/MD5

   XML: https://en.wikipedia.org/wiki/XML

On Thu, Sep 26, 2019 at 5:15 AM Hakala, Juha E <[email-masked]<mailto:[email-masked]>> wrote:
Hello Philip,

as regards this:

Please tell me whether it is necessary for a urn to be able to uniquely locate files as well as classify them?

URNs don’t have to be provide resolution services, so the resolver (if any) does not need to know the location or locations of the identified resource, or to link the URN to these URL / URLs. You may want to mention in the urn:gbs namespace registration request that no resolution services are anticipated.

It might be useful to add to the request the sentences below on document types and <T> values, with a note that for the time being only Dita documents are within scope. And some background information about Dita might be useful as well, for those who are not familiar with it.

Best regards,

Juha

Lähettäjä: urn <[email-masked]<mailto:[email-masked]>> Puolesta Philip R Brenan
Lähetetty: keskiviikko 25. syyskuuta 2019 21.46
Vastaanottaja: [email-masked]<mailto:[email-masked]>
Kopio: [email-masked]<mailto:[email-masked]>; Dale R. Worley <[email-masked]<mailto:[email-masked]>>
Aihe: Re: [urn] gbs Name space identifier

I have removed the link in question as the explanation of the derivation of the <T> component was deemed unsatisfactory.  Here is what I was trying to achieve:

It is anticipated that the GB Standard represented by the urn: gbs name space could be usefully applied to a number of different document types, such as Dita, DocBook, Word, Html etc.  The <T> component is designed to separate these various name spaces. At the moment the only <T> in active use  is dita for Dita documents.  Within the Dita space the algorithm for computing the <G> component is included in:

https://metacpan.org/pod/Dita::GB::Standard

as gbStandardFileName().

The computation of the <G> component is performed by examining the text between which ever of the following xml tags exist in a particular Dita document in the order in which they appear:

 title mainbooktitle booktitlealt

The text between these tags is used to form the <G> component after converting runs of all characters other than a-zA-Z0-9 to single underscores. This method was chosen because it produces the most readable names that are closely aligned with what authors expect to see as a file name.

The purpose of the GB Standard is to control the explosion of duplicate Dita topics that tends to occur as documents evolve.  Typically when a new product is documented, the author takes the existing set of linked topic files comprising the documentation of the product, duplicates all of these files to preserve the linkage structure,  then makes a small number of changes to a few of the duplicated files, leaving the bulk of the topic files unchanged.  It is difficult to reuse the original topic files in situ because of the need to maintain the links between them.

The GB Standard seeks to reduce this exponential growth of topic files by giving each topic a unique deterministic name so that links between topics can be expressed in a way that endures as the topic files are copied over time.

As proposed, the GB Standard allows a server to quickly determine whether it has a copy of a file by computing the GB Standard name of an incoming file and comparing it to the names of all such files stored locally.   If the name already exists then that file is reused, if the name does not exist on the server then the server adds the incoming file to its list of files available.

It is not the current intention to use the GB Standard name to locate off site copies of a file - as things stand this could only be achieved by querying each server known to store files in this manner in turn.  Please tell me whether it is necessary for a urn to be able to uniquely locate files as well as classify them?  If it is a requirement that a urn can be used to locate a topic file anywhere in the world then I need to rethink this aspect of the GB Standard and update my application for the gbs namespace accordingly.  If location is not necessarily required then the description of the computation of the <G> component and adequate documentation of the standard names in the <T> would be seem to be the elements that need work to progress this application further?

On Tue, Sep 24, 2019 at 12:51 PM <[email-masked]<mailto:[email-masked]>> wrote:
> >    <T> is a string of one or more characters drawn from: [a-zA-Z0-9_] which
> >    identifies the type of content from a list of types published by the
> >    registrant at https://metacpan.org/pod/Dita::GB::Standard::Types .
>
> I attempted to obtain the list of valid types at the given URL, but was
> unsuccessful.  That page seemed to be a very top-level discussion of
> "The GB Standard".

That URL gives me a 404...

Best,

Lars

--
Thanks,
Phil<https://opentokrtc.com/room/phil>
Philip R Brenan<https://opentokrtc.com/room/phil>

--
Thanks,
Phil<https://opentokrtc.com/room/phil>
Philip R Brenan<https://opentokrtc.com/room/phil>

---

From: Philip R Brenan <[email-masked]>
Date: Fri, 4 Oct 2019 00:33:02 +0100

Hi *Juha*:

I would be pleased to elevate this proposal to ISO status and play what
every role is required of me in that process if there is some-one in your
group who is willing to guide my actions to make this happen.  To that end
I have made the suggested edit to remove the superfluous *h* from the
proposed standard and attached the results as a file for easy reference.
Please tell me how I might progress this application further?

On Wed, Oct 2, 2019 at 5:42 AM Hakala, Juha E <[email-masked]>
wrote:

> Hello Philip,
>
>
>
> as far as I am concerned, the application does not require any further
> editing, except that you should remove the extra “h” from
>
>
>
> hhttps://metacpan.org/pod/Dita::GB::Standard
>
>
>
> IMO one of the main challenges with namespace registration requests has
> been that the authors themselves usually know well the intended scope the
> proposed namespace. Alas, it may be difficult to communicate this
> information to reviewers who might not be familiar with the context. The
> text below is now pretty good at explaining the initial usage of  urn:gbs
> identifiers.
>
>
>
> I think it is a good idea that there is also room for growth. In ISO TC
> 46/SC 9 (which deals with ISO standard identifiers like ISSN, ISBN and DOI)
> we recently evaluated a new work item proposal for an identifier that would
> have been machine generated from the content of the identified textual
> resource like urn:gbs:dita’s. Alas, the proposed syntax and algorithms were
> not rigorous enough, and the proposal was not approved.
>
>
>
> As an aside, in order to make urn:gbs:dita’s ISO standard identifiers, it
> would be necessary to standardize just RFC 8141 in ISO. Would you have any
> interest on elevating the status of urn:gbs like that? Since IETF is
> Category A liaison with ISO TC 46, fast track process could be used to
> create quickly an ISO standard which is identical with the original one.
>
>
>
> All the best,
>
>
>
> Juha
>
>
>
> *Lähettäjä:* Philip R Brenan <[email-masked]>
> *Lähetetty:* sunnuntai 29. syyskuuta 2019 16.57
> *Vastaanottaja:* Hakala, Juha E <[email-masked]>
> *Kopio:* [email-masked]; [email-masked]; Dale R. Worley <
> [email-masked]>
> *Aihe:* Re: [urn] gbs Name space identifier
>
>
>
> Hi *Juha*:
>
>
>
>    E-mail:  [email-masked]
>    hhttps://metacpan.org/pod/Dita::GB::Standard
>
>    Dita specification:
> On Thu, Sep 26, 2019 at 5:15 AM Hakala, Juha E <[email-masked]>
> wrote:
>
> Hello Philip,
>
>
>
> as regards this:
>
>
>
> Please tell me whether it is necessary for a *urn* to be able to uniquely
> locate files as well as classify them?
>
>
>
> URNs don’t have to be provide resolution services, so the resolver (if
> any) does not need to know the location or locations of the identified
> resource, or to link the URN to these URL / URLs. You may want to mention
> in the urn:gbs namespace registration request that no resolution services
> are anticipated.
>
>
>
> It might be useful to add to the request the sentences below on document
> types and <T> values, with a note that for the time being only Dita
> documents are within scope. And some background information about Dita
> might be useful as well, for those who are not familiar with it.
>
>
>
> Best regards,
>
>
>
> Juha
>
>
>
> *Lähettäjä:* urn <[email-masked]> *Puolesta *Philip R Brenan
> *Lähetetty:* keskiviikko 25. syyskuuta 2019 21.46
> *Vastaanottaja:* [email-masked]
> *Kopio:* [email-masked]; Dale R. Worley <[email-masked]>
> *Aihe:* Re: [urn] gbs Name space identifier
>
>
>
> I have removed the link in question as the explanation of the derivation
> of the *<T>* component was deemed unsatisfactory.  Here is what I was
> trying to achieve:
>
>
>
> It is anticipated that the GB Standard represented by the *urn:* *gbs*
> name space could be usefully applied to a number of different document
> types, such as Dita, DocBook, Word, Html etc.  The <T> component is
> designed to separate these various name spaces. At the moment the only <T>
> in active use  is *dita* for Dita documents.  Within the Dita space the
> algorithm for computing the *<G>* component is included in:
>
>
>
> The computation of the <G> component is performed by examining the text
> between which ever of the following *xml* tags exist in a particular Dita
> document in the order in which they appear:
>
>
>
> converting runs of all characters other than a-zA-Z0-9 to single
> underscores. This method was chosen because it produces the most readable
> names that are closely aligned with what authors expect to see as a file
> name.
>
>
>
> The purpose of the GB Standard is to control the explosion of duplicate
> Dita topics that tends to occur as documents evolve.  Typically when a new
> product is documented, the author takes the existing set of linked topic
> files comprising the documentation of the product, duplicates all of these
> files to preserve the linkage structure,  then makes a small number of
> changes to a few of the duplicated files, leaving the bulk of the topic
> files unchanged.  It is difficult to reuse the original topic files in situ
> because of the need to maintain the links between them.
>
>
>
> The GB Standard seeks to reduce this exponential growth of topic files by
> giving each topic a unique deterministic name so that links between topics
> can be expressed in a way that endures as the topic files are copied over
> time.
>
>
>
> As proposed, the GB Standard allows a server to quickly determine whether
> it has a copy of a file by computing the GB Standard name of an incoming
> file and comparing it to the names of all such files stored locally.   If
> the name already exists then that file is reused, if the name does not
> exist on the server then the server adds the incoming file to its list of
> files available.
>
>
>
> It is not the current intention to use the GB Standard name to locate off
> site copies of a file - as things stand this could only be achieved by
> querying each server known to store files in this manner in turn.  Please
> tell me whether it is necessary for a *urn* to be able to uniquely locate
> files as well as classify them?  If it is a requirement that a *urn *can
> be used to locate a topic file anywhere in the world then I need to rethink
> this aspect of the GB Standard and update my application for the *gbs*
> namespace accordingly.  If location is not necessarily required then the
> description of the computation of the <G> component and adequate
> documentation of the standard names in the <T> would be seem to be the
> elements that need work to progress this application further?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Sep 24, 2019 at 12:51 PM <[email-masked]> wrote:
>
> Phil <https://opentokrtc.com/room/phil>
>
> Philip R Brenan <https://opentokrtc.com/room/phil>
>
>
>
> --
>
> Thanks,
>
> Phil <https://opentokrtc.com/room/phil>
>
> Philip R Brenan <https://opentokrtc.com/room/phil>
>

-- 
Thanks,

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

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

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 16 Oct 2019 21:37:10 -0400

"Hakala, Juha E" <[email-masked]> writes:
> IMO one of the main challenges with namespace registration requests
> has been that the authors themselves usually know well the intended
> scope the proposed namespace. Alas, it may be difficult to communicate
> this information to reviewers who might not be familiar with the
> context.

True.  But of course, one of the purposes of a URN registration is to
communicate to the public the intended scope of the proposed namespace.
(RFC 8141, section 6.4.1, item 2)  We're here to help registrants do
that.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 16 Oct 2019 21:59:32 -0400

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:

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:

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 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

---

From: Philip R Brenan <[email-masked]>
Date: Mon, 21 Oct 2019 17:35:11 +0100

Hi *Dale*:

Thank you for raising these important issues.  I have updated the text of
the
proposal (attached) in light of your helpful comments.

I have corrected the error made on my part regarding MD5 collisions that you
kindly noted. It now reads:

    Equivalence is determined by comparing (ignoring case) just the <B>
    components of the two topics to be compared.  If they are equal the two
    topics are considered to be equal, even if, as a result of an MD5
collision
    the content of the underlying documents is in fact different. The
    characteristics of the MD5 sum make such an occurrence extremely
unlikely,
    see for example Mead:

    "Unique File Identification in the National Software
     Reference Library"

    at:

    https://www.nist.gov/sites/default/files/draft-060530.pdf

    Authors who have concerns over the possible impact of an MD5 collision
    on their work should not use this name space.

My rationale for this change is as follows:

All URN name spaces that do not contain the content of the actual topic in
question are, in effect, digests that seek to use a finite string to name
one
topic drawn from a potentially uncountable set of topics. For each such
digest
there must then be an uncountable number of other topics that could also
yield
that digest.  Consequently, in theory, all such name spaces suffer from
collisions. In practice, only a finite number of topics need to be named, so
the design of a URN name space becomes one of engineering: is the collision
rate sufficiently low to be acceptable in the proposed application?

In developing this proposal I initially considered various incremental
numbering schemes. These schemes were deemed failures as they required
collections of documents to communicate in real time to avoid name
collisions.

I then considered the CRC-32, MD4, MD5 and SHA-2 series of hash functions.
Of
these, MD5 was the shortest digest that appeared to offer an acceptable
collision rate, following the study done by Mead:
https://www.nist.gov/sites/default/files/draft-060530.pdf

As the URN identifying a document is likely to be frequently embedded in XML
and to appear in reports, presentations, program stack trace backs, spread
sheets, web pages, database indices etc. a shorter digest is preferable to a
longer one as long as the collision rate is acceptable.

MD5 is a useful compromise between the need to produce names that can be
used
in a variety of applications and contexts by both humans and computers while
maintaining a low enough collision rate. CRC-32 and MD4 were deemed too
unreliable.  SHA-2 was rejected on the grounds that the minimal improvement
in
reliability obtained in the proposed application space failed to justify the
extra overhead induced by the longer digests.

Consequently MD5 was chosen as the appropriate digest based on operational
experience obtained after trying a number of other possibilities.  If in the
light of further operational experience it becomes apparent that some other
digest would be more appropriate the <T> component provides space within
which
to adopt the new digest over time.

May I therefore urge that MD5 is an appropriate choice for now and that
adoption of this particular proposal should not be made dependent on finding
a perfect digest?

In Security and Privacy, following your suggestion, I have clarified that
access to the content named by the URN is required to check the validity of
the
URN as follows:

   Access to the content of the topic named by the URN is required to check
the
   validity of the URN. The validity of the URN for a topic can be checked
as
   follows: ...

May I propose that the need to access the content of a URL or URN to fully
validate the URI is a common feature of all name spaces as evinced by the
existence of HTTP code 404 and thus should not, in of itself, impede the
adoption of this particular proposal?

On Inter-operability, following your suggestion, I have clarified why case
is
often immaterial in anticipated operations on this name space as follows:

   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 representation of the <B> component is in
lowercase
   to minimize its visual impact on human readers, the lower case form can
   easily be recovered from a mixed case form making the <B> component, in
   effect, insensitive to case.

   The MD5 sum represented by the <B> component can undergo degradation in,
   copying, storage or transmission yet still be recoverable by querying
   significant collections of topics for topics with similar <B> components
   given that the anticipated size of the topic space is of order 1e10
versus
   an MD5 space size of order 1e38.

   Ideally, the <G> component should be presented in the case designated by
the
   original author of the topic.  In cases where this is not possible, the
<G>
   component can undergo degradation and still remain useful, for example:
high
   degradation rates in the <G> component have been noticed when the <G>
   component is spoken out loud by people collaborating in a shared work
space
   on less than 1e2 topics. The <G> component has a space size of at least
1e6
   as evinced by the number of Wikipedia articles in English:

   https://www.wikipedia.org/

   Operational experience has confirmed, so far, that the <G> component is
   capable of tolerating the significant degradation of case and spelling
that
   normally occurs in human speech.

   If the <G> component of two topics is intentionally identical or
identical
   after degradation then the identity of a specific topic can be confirmed
by
   saying the first few characters of its <B> component using a phonetic
   alphabet, such as the one used by NATO:

   https://en.wikipedia.org/wiki/NATO_phonetic_alphabet.

   It is anticipated that names from the proposed name space will be
embedded
   in XML topic references, file names, URL queries and commands entered
via the
   command line.  XML is sensitive to spaces and the following characters:

     <>'"=&

   File systems are often sensitive to file names containing:

     :/\.

   The query portion of a URL is sensitive to:

     &=#

   The command line is sensitive to spaces and:

     "'\$()[]{}

   The <T>, <G>, <B> components avoid these characters to facilitate
   inter-operability between these systems.

   To facilitate the construction of file names and URLs containing
references
   to topics named by this proposed name space, the formal name assigned by
   this proposal may be intentionally degraded by omitting the words 'urn'
and
   'gbs', omitting the <T> component, replacing the colon between the <G>
and
   <B> components with an underscore and adding a file name extension if the
   formal URN can be reliably recovered from the degraded version in the
   context within which the degraded version is being used. In such a
context,
   a formal URN:

   may be intentionally degraded to:

     Introduction_to_the_GB_Standard_dddb7e2c29d2c8b9d87187fdf52a2702.xml

   Other acceptable degradation will be published as updates to this
document.

   Dita topics that do not contain ASCII characters suitable for
constructing
   the <G> component will be accommodated by adding a new value to the list
of
   values accepted by the <T> component and specifying the corresponding
   algorithm for computing the <G> component in an update to this document.

During the development of the proposed name space I experimented with
alternative representations of the <B> component, specifically:
representing it
in base64 and in decimal.  Base64 had the disadvantage that the
predominance of
letters over numbers made it harder for humans to separate it from the <G>
component.  The decimal representation overcame this problem but at the
expense
of a longer <B> component.  Just as MD5 seems to offer a useful balance
between
length and collision rate in computations on the <B> component,
representation
of the <B> component in lowercase hexadecimal seems to offer a useful
balance
between length and the speed at which humans can separate it from the <G>
component.  If, as a result of further operational experience, it becomes
apparent that a better representation of the <B> component is available then
the <T> component allows names withing the proposed name space to be
upgraded
over time.

May I therefore represent that the proposed name space is usefully
resilient to
changes in case and the other degradations likely to occur during usage
while
maintaining a usable balance between the needs of humans versus computers?

In summary: may I urge that the combination of the <G> and <B> components in
the proposed name space represents a useful advance in the art of naming
Dita
topics and that consequently the proposed name space can be safely approved?

-- 
Thanks,

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 21 Oct 2019 22:12:20 -0400

> adoption of this particular proposal should not be made dependent on finding

I have no complaint against the use of MD5.  If I commeneted on it, I
expect that the cause was that some part of the text was unclear or
inexact.

> adoption of this particular proposal?

I have no concern about whether the URN can be validated.  But it's
common when a "validation" procedure is given, that it does not require
access to the designated resource itself.  So it is useful to the reader
to note that this procedure involves checking the URN against the
resource.

> On Inter-operability, following your suggestion, I have clarified why
> case is often immaterial in anticipated operations on this name space
> as follows:
>
>    For many computations, the case of the letters in the URN is immaterial and
>    although the preferred representation of the <B> component is in lowercase

True ... but you're avoiding looking at the fact that you've *defined*
these URNs to use lower-case MD5.  If that field contains upper-case
letters, the whole URN is invalid.  Of course, if you see what *looks*
like a gbs URN with upper-case letters there, you might convert them to
lower-case to see if you get a valid URN, but that's like a computer
program with typos in it, a human might be able to get useful
information out of it, but you wouldn't want to depend on a computer
doing so.

OTOH, you could *define* that the MD5 portion is case-insensitive.  It's
your choice.

Dale

---

From: Philip R Brenan <[email-masked]>
Date: Wed, 23 Oct 2019 18:38:24 +0100

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?

-- 
Thanks,

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 24 Oct 2019 20:26:54 -0400

Philip R Brenan <[email-masked]> writes:
> 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.

Yes, this looks good to me.

Dale