Re: draft-reed-urn-dgiwg-00

Leslie Daigle <leslie@thinkingcat.com> Wed, 18 November 2009 23:33 UTC

Return-Path: <leslie@thinkingcat.com>
X-Original-To: urn-nid@core3.amsl.com
Delivered-To: urn-nid@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A91B28C141 for <urn-nid@core3.amsl.com>; Wed, 18 Nov 2009 15:33:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level:
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Af-41VNADcb for <urn-nid@core3.amsl.com>; Wed, 18 Nov 2009 15:33:32 -0800 (PST)
Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id BAB3328C133 for <urn-nid@ietf.org>; Wed, 18 Nov 2009 15:33:28 -0800 (PST)
Received: from beethoven.local ([::ffff:209.183.196.229]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 18 Nov 2009 18:33:24 -0500 id 015B007E.4B048444.00004A5E
Message-ID: <4B04843C.5040707@thinkingcat.com>
Date: Wed, 18 Nov 2009 18:33:16 -0500
From: Leslie Daigle <leslie@thinkingcat.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Carl Reed <creed@opengeospatial.org>
Subject: Re: draft-reed-urn-dgiwg-00
References: <200910262124.WAA27234@TR-Sys.de> <493F67A76AEC4F92934B2C570B9F4386@CarlandSusieOf>
In-Reply-To: <493F67A76AEC4F92934B2C570B9F4386@CarlandSusieOf>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: urn-nid@ietf.org, Alfred HÎnes <ah@TR-Sys.de>
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn-nid>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Nov 2009 23:33:33 -0000

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" <ah@TR-Sys.de>
> To: <urn-nid@ietf.org>
> 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: (+49)7156/9635-0, Fax: -18         |
>> | D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
>> +------------------------+--------------------------------------------+
>>
> 

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
leslie@thinkingcat.com
-------------------------------------------------------------------