Re: draft-reed-urn-dgiwg-00

["Carl Reed" <[e-mail]>]

Alfred -

I asked the DGIWG community about your fundamental question. To wit:

DGIWG is a coalition of Military partners and at times the
users of DGIWG information will be operating in closed environments (not
on WWW) doesn't it make sense to not have the DGIWG namespace tied so
closely to the OGC one?

Further, the vast majority of DGIWG documents and resources, such as feature 
identifiers, is significantly beyond the scope of the work of the OGC and 
the expertise of the OGC Naming Authority.

My name is on the document as editor because the DGIWG community asked me to 
help them.

Does this answer your concern?

Thanks and regards

Carl


----- Original Message ----- 
From: "Alfred HÎnes" <[e-mail]>
To: <[e-mail]>
Sent: Monday, October 26, 2009 2:24 PM
Subject: draft-reed-urn-dgiwg-00


> Hello,
> I have taken a detailed look a your recent I-D,
>   draft-reed-urn-dgiwg-00,
> and have a few comments, one fundamental and a bunch of mostly
> editorial topics (presented roughly in textual order).
>
>
> (0)  Fundamental:  Namespace consideration
>
> Could this namespace not reasonably be implemented as a delegation
> branch within the OGC URN namespace, to which the target subject
> of the draft seems to be very closely related?
> [ Question triggered by draft author's affiliation! ]
>
>
> (1)  General
>
> I suggest to consistently place the definite article in front of
> "DGIWG".
>
>
> (2)  Section 2
>
> (2.1)  general
>
> I suggest (for enhanced readability) that you make use of consistent
> indentation steps and levels for all clauses of the template in this
> section.  The RFC Editor prefers a consistent indentation stepwidth
> of 3 character positions.
>
> (2.2)  Leading clause
>
> I believe that this can be simplified instantaneously to say:
>
> |  Namespace ID: dgiwg
>
> Anything other will not really satisfy your request, isn't it? -- and
> it would be contrary to the section headline and Section 7 as well!
>
> (2.3)  "Declared registrant ..."
>
> Perhaps adding "Postal:"  to parallel the "Name:" already present,
> and adding more line breaks would improve the clarity and readability
> of the clause.
>
> (2.4)  "Declaration of syntactic structure:"
>
> 1st para:
>
> |   The Namespace Specific String (NSS) of all URNs that use the "nena"
>    NID will have the following structure:
>
> Ooops!   "nena" NID  ??  --  caught in copy-edit trap !?!
>
> 2nd para:
>
> o  To disambiguate the NSS syntax, you need to specify that the
>   {DGIWGresource}  part does not contain the colon (":") character,
>   isn't it?.
>
> 3rd para (and other places):
>
> o  "NRS" -- what the heck does the "N" stand for ?
>   Could you please give a precise acronym expansion on first use?
>   In case it simply is a not-so-meaningful name of the system
>   you could say somewhere:
>
>   ... the DGIWG Registration System (called "NRS") ...   [or similar].
>
> o  'DGIWGresources"' -- unmatched double-quotes !
>
> (2.5)  "Relevant ancillary documentation:"
>
> o  The trailing period is missing after the 2nd sentence in this clause,
>   "These are maintained by the DGIWG"
>
> o  Suggested language improvement:
>
>   More information about NRS and the registration activities and
> |  procedures to be followed are defined in document on the "Concept of
>   Operations for Registration", which provides the procedures for the
> |  DGIWG registration of geographical items.
> ---                      vvvvv
> |  More information about the NRS and the registration activities and
> |  procedures to be followed can be found in the document, "Concept of
>                             ^^^^^^^^^^^^   ^^^^^        ^
>   Operations for Registration", which provides the procedures for the
> |  DGIWG registration of geographical items; URL:
>                                           ^^^^^^
>
> o  Is the URI presented a sufficiently stable URL ?
>   AFAICT, the RFC Editor and IANA prefer more mnemonic URLs;
>   in fact, experience has shown that URLs containing apparent
>   implementation details (here: question part "?artifact_id=3526")
>   frequently are less stable; be prepared for this URI being
>   challenged by the RFC Editor!
>
> (2.6)  "Identifier uniqueness considerations:"
>
> "and subsequent strings associated."   seems to be truncated.
>
> You have previously introduced the terms "class of resource type"
> for the  DGIWGresource  component of the NSS.
> In retrospect, it might be even better to more simply say "class
> of resources" or "resource type" only.   I would appreciate
> if you could use consistently the same term (of your preference),
> since that would make the presentation much more clear and precise.
> So perhaps the first sentence of this clause should become:
>
>   The NRS will manage resources using the "dgiwg" NID and will be the
> |  authority for managing the resource type identifiers and subsequent
> |  strings associated with them.  [...]
>
> (2.7)  "Process for identifier resolution:"
>
> The acronym "RDS" is neiter expanded here nor does it appear anywhere
> else in the draft; I's suggest to avoid the acronym and use the
> exoanded form only in such case(s).
>
>
> (3)  IANA Considerations
>
> This section should point to Section 2 as containing the
> registration template and specify the origin of the template
> and the procedures followed (RFC 3406).
>
> For instance:
>
> |  This document registers with IANA a new Formal URN Namespace ID,
> |  "dgiwg", following the procedures in RFC 3406 [RFC3406]; the
> |  completed registration template is in Section 2 of this document.
> |  The affected IANA registry is currently located at
> |  http://www.iana.org/assignments/urn-namespaces.
>
> Text in this style has the outstanding property that the RFC Editor
> does not have to change much for temporal consistency after the
> IANA registration actually has been performed, thus reducing the
> potential for clerical errors introduced in final stages of the
> publication process.   (In this case, the RFC Editor will most
> likely simply remove the last sentence that only serves as an
> assistance and counter-check for IANA during pre-publication
> processing.)
>
>
> (4)  References
>
> The first 3 entries in Section 8 are doubtlessly Normative!
>
> (The guides on the RFC Editor web site explain the term
> "Normative Reference" as 'needed to understand the document'.)
>
> I refrain from arguing about the kind of the final one, but
> that lacks the proper bracketed reference tag, and it lacks
> quotation of the title and more details (as does the 3rd entry).
>
> Please compare with (ISO or similar) "3rd party" references
> in contemporary RFCs for examples of how these should better
> appear for bibliographic precision (minimum IPR requirements
> for citations).
>
>
> Kind regards,
>  Alfred HÎnes.
>
> -- 
>
> +------------------------+--------------------------------------------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
> | Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
> | D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
> +------------------------+--------------------------------------------+
>