Re: draft-reed-urn-dgiwg-00

[Leslie Daigle <[e-mail]>]

And, to be clear... I think you recall that the proponents of the 
namespace are supposed to forward the I-D to this mailing list for a 
review when (they believe) it is ready for publication.

Alfred is helping you out with some advance input!  but I will still ask 
you to formally send the I-D to the list when you're ready to consider 
publishing it.

Thanks,
Leslie.



Carl Reed wrote:
> 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]                     |
>> +------------------------+--------------------------------------------+
>>
> 

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[e-mail]
-------------------------------------------------------------------