Re: draft-reed-urn-dgiwg-01

"Carl Reed" <creed@opengeospatial.org> Tue, 02 February 2010 17:39 UTC

Return-Path: <creed@opengeospatial.org>
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 66F873A6828 for <urn-nid@core3.amsl.com>; Tue, 2 Feb 2010 09:39:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 GLU86w4xlAlA for <urn-nid@core3.amsl.com>; Tue, 2 Feb 2010 09:39:28 -0800 (PST)
Received: from mail.opengeospatial.org (mail.opengeospatial.org [66.244.86.40]) by core3.amsl.com (Postfix) with ESMTP id B2EEB3A672E for <urn-nid@ietf.org>; Tue, 2 Feb 2010 09:39:27 -0800 (PST)
Received: from CarlandSusieOf (c-76-25-20-162.hsd1.co.comcast.net [76.25.20.162]) (authenticated bits=0) by mail.opengeospatial.org (8.13.8/8.13.8/Debian-3) with ESMTP id o12HdxDa015741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 2 Feb 2010 12:40:01 -0500
Message-ID: <E97351E6B41340338E4D89EC4B066E89@CarlandSusieOf>
From: Carl Reed <creed@opengeospatial.org>
To: Leslie Daigle <leslie@thinkingcat.com>
References: <200910262124.WAA27234@TR-Sys.de> <493F67A76AEC4F92934B2C570B9F4386@CarlandSusieOf> <4B04843C.5040707@thinkingcat.com>
In-Reply-To: <4B04843C.5040707@thinkingcat.com>
Subject: Re: draft-reed-urn-dgiwg-01
Date: Tue, 02 Feb 2010 10:36:51 -0700
Organization: OGC
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_00CC_01CAA3F3.A15345D0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.16480
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
X-Virus-Scanned: ClamAV 0.92.1/10350/Tue Feb 2 06:43:06 2010 on mail.opengeospatial.org
X-Virus-Status: Clean
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: Tue, 02 Feb 2010 17:39:30 -0000

Leslie -

Attached is the version we believe is ready for publication. We have 
incorporated Alfred's suggested changes.  I have also been using idnits to 
check for any formatting errors, etc.

Comments welcome.

Thanks for your patience.

Regards

Carl Reed
CTO
OGC

----- Original Message ----- 
From: "Leslie Daigle" <leslie@thinkingcat.com>
To: "Carl Reed" <creed@opengeospatial.org>
Cc: "Alfred HÎnes" <ah@TR-Sys.de>; <urn-nid@ietf.org>
Sent: Wednesday, November 18, 2009 4:33 PM
Subject: Re: draft-reed-urn-dgiwg-00


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