Subject: Re: Request for comments: Delegation of urn:ogf

From: Freek Dijkstra <[email-masked]>
Date: Sat, 09 Jul 2011 22:10:25 +0200

Hello Peter,

Last month you send feedback on
http://tools.ietf.org/html/draft-dijkstra-urn-ogf. I just updated and
uploaded a revised document.

Rest assured that my long delay in updating the document had nothing to
do you with your clear and very useful comments. Thank you.

Peter Saint-Andre wrote:

>>> http://tools.ietf.org/html/draft-dijkstra-urn-ogf
> 
> With regard to the identifier uniqueness considerations, please make it
> clear whether the Open Grid Forum's Technical Director will ever assign
> secondary responsibility for management of any sub-trees, and whether it
> will be permissable to re-assign URNs. (My recommendation is to say you
> won't do those things.)

The text was changed to say subdelegation is permissible, but
re-assignment is not.

> With regard to resolution, the I-D says:
> 
>    OGF will maintain an index of all subnamespace identifiers on its Web
>    site, http://www.ogf.org/urn/.
> 
>    Resolution mechanism of SUBNAMESPACE-SPECIFIC-STRING within each SNID
>    MUST be defined before assignment of a subnamespace identifier.
> 
> I think instead you want to say something like this:
> 
>       The namespace is not currently listed with a Resolution
>       Discovery System (RDS), but nothing about the namespace
>       prohibits the future definition of appropriate resolution
>       methods or listing with an RDS.

You are absolutely correct. I misinterpeted the meaning of this section,
and it now contains a text very close to your above quote.

>>> For review, I particularly appreciate feedback on the text dealing
>>> forward compatibility with RFC2141bis. (I obviously can't refer to that
>>> document yet, but at the same time want subnamespaces to be prepared for
>>> future changes).
> 
> I think it is best not to prejudge the outcome of the revision process.
> You can always update this document, or the relevant OGF specifications
> governing issuance of urn:ogf:* URNs, if and when the base spec changes.

Agreed. I changed the text to what I hope is a bit more tangible
impleemntation of Jon Postels' robustness principle:

   Documents defining a subnamespace identifier SHOULD specify further
   syntactic restrictions in SUBNAMESPACE-SPECIFIC-STRING.  It is
   RECOMMENDED that these documents forbid the assignment of URNs
   containing characters in the <reserved> set ("%", "/", "?", and "#")
   as defined in [RFC2141].

   For forward compatibility, it is RECOMMENDED that software
   implementations that accept generic OGF URNs, but don't make
   subnamespace-specific validity checks, allow all characters defined
   by pchar in [RFC3986]. pchar contains the characters in <URN-char>,
   as well as "&" and "~".

Let me know if you see any other room for improvement, or would
recommend sending this to the IESG as-is.

Thanks a lot for your effort,
Freek Dijkstra

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 10 Jul 2011 07:05:38 +0300

Hello Freek,

I have several comments on your document.

 From Section 2.4:
>     This
>     document does not pose any additional restrictions to the
>     SUBNAMESPACE-SPECIFIC-STRING other than what is defined in the NSS
>     syntax as defined by [RFC2141] or its successor:
>
>        SUBNAMESPACE-SPECIFIC-STRING  =  1*<URN chars>
>
>     <URN chars>  is defined in Section 2.2 of [RFC2141].
I see RFC 2141 didn't use ABNF for definition, so it's impossible to 
import the <URN chars> rule from their.  It may be displayed as follows:
>        SUBNAMESPACE-SPECIFIC-STRING  = 1*uchar
>        uchar       = trans / pct-encoded
>        trans       = ALPHA / DIGIT / other-uchar
>        other-uchar = "(" / ")" / "+" / "," / "-" / "." /
>                      ":" / "=" / "@" / ";" / "$" / "_" /
>                      "!" / "*" / "'"
>        pct-encoded = "%" 2HEXDIG
This definition deliberately excludes RFC 2141 <reserved> from allowed 
chars.  This is an accordance with RFC 3986.

Moreover, such definition will require changing the following text (and 
the whole Section 2.11):
>     It is
>     containing characters in the<reserved>  set ("%", "/", "?", and "#")
>     as defined in [RFC2141].
My proposal is to mention that RFC 2141 <reserved> chars are 
deliberately excluded from the allowed in <SUBNAMESPACE-SPECIFIC-STRING> 
because of restrictions made by RFC 3986, explicitly Section 2.2 of it.  
Such characters should be percent-encoded if occur.

Section 2.5, Ancillary documentation.  I think a here should be a 
reference to your GFD.1 publication, describing the GFD series.

So far, I see, OGF has published 189 GFDs.  Is your draft going to 
provide a reservations for something like "legacy" GFDs, eg. 
"urn:ofg:legacy:<number>" or this will be left to OFGF Director?  
Anyway, your document should mention the relationships between 
so-far-published GFDs and OGF URNs.

As an editorial comment: all ABNF productions should be enclosed in 
angle brackets, as recommended by RFC 5234:
>     Unlike original BNF, angle brackets ("<",">") are not required.
>     However, angle brackets may be used around a rule name whenever their
>     presence facilitates in discerning the use of a rule name.
Thanks,
Mykyta Yevstifeyev

09.07.2011 23:10, Freek Dijkstra wrote:
> [ . . . ]

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 15 Jul 2011 11:35:39 -0600

Thanks for the update. I'd be happy to sponsor this document for you.

---

From: Freek Dijkstra <[email-masked]>
Date: Fri, 15 Jul 2011 14:00:05 -0600

Hello Mykyta,

Thanks for reading our draft and providing useful comments!

>>        other-uchar = "(" / ")" / "+" / "," / "-" / "." /

You are correct. Indeed RFC 2141 uses BNF instead of ABFN, so you can
not import that as-is.

I'm a bit hesitant to add this to the draft, though. In practice, people
who want to use ABNF can easily translate the BNF from RFC 2141 themselves.

The reason I'm hesitant is that such definition (or should be) in
RFC2141bis, not in this document.

Given that RFC2141bis is not finished, I don't know what will be in
there. For example, your definition deliberately excludes RFC 2141
<reserved> from allowed chars. RFC2141bis may make a different decision.
I hope to avoid such potential ambiguity by simply referring to RFC2141.

> Such characters should be percent-encoded if occur.

This is a useful clarification, I'll gladly include it, thanks.

> reference to your GFD.1 publication, describing the GFD series.

I referred to the URL page that lists the series. Indeed, it is better
to refer to GFD.1 instead.

> so-far-published GFDs and OGF URNs.

No, this draft will not defined how to define subnamespaces. It is
planned that this is done in a GFD document. A draft of that document is
provided at http://forge.ogf.org/sf/go/artf6478.
I expect that is needs a revision or two.

>>     presence facilitates in discerning the use of a rule name.

Ah, thanks. This indeed makes it more readable. I'll fix this too.

Freek.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 23 Jul 2011 11:47:53 +0300

Hello Freek,

Sorry for late response.  Please see my comments in-line.

15.07.2011 23:00, Freek Dijkstra wrote:
>> import the<URN chars>  rule from their.  It may be displayed as follows:
I also thought of RFC 2141bis, and as it isn't finished yet, we can't 
know for sure what it will imply.  However, given that RFC 3986 is a 
current Standard which is in force, RFC 2141bis will be compatible with 
it.  RFC 3986 restricts use of RFC 2141 <reserved> in any part of URI 
for the purpose other than:

>     <reserved>     ::= '%"
percent-encoding,
> | "/"
delimiting path components (segments),
>   | "?"
delimiting query, and
>   | "#"
delimiting fragment identifier.  Correspondingly, RFC 3986 <sub-delims>, 
which are allowed in <segment>s, don't include the aforementioned 
characters.  Even if URNBIS WG decides not to allow queries and/or 
fragment identifiers in URNs, won't be capable of allowing the RFC 2141 
<reserved> to be present in a URN "in the raw" - not percent-encoded.

Moreover, RFC 2141 just limits the range of chars to be present in URNs 
whereas specific namespace specifications may place their limitations.  
I recommend, in order to be compatible with RFC 3986, don't allow RFC 
2141 <reserved> in the sub-namespace ID.

>> My proposal is to mention that RFC 2141<reserved>  chars are
>> deliberately excluded from the allowed in<SUBNAMESPACE-SPECIFIC-STRING>
Yes, please, especially if you incorporate the first comment.
> to refer to GFD.1 instead.
Thanks for this.
> I expect that is needs a revision or two.
I suppose that this document should also be referenced in your Section 2.8.
> Ah, thanks. This indeed makes it more readable. I'll fix this too.
Thanks for your corrections,
Mykyta Yevstifeyev

---

From: Freek Dijkstra <[email-masked]>
Date: Sun, 24 Jul 2011 22:06:48 +0200

> delimiting fragment identifier.

Both RFC 2141 and RFC 3986 are clear.

What I'm saying is that I rather not include parts of these RFCs in this
urn:ogf document, but strongly prefer to _refer_ to them, even if that
means referring to a BFR notation instead of a ABFR notation.

I hope the references are now clear and unambiguous in my latests draf.

The draft submission tool is still hold (in preparation of the upcoming
IETF), so I attached the latest version. I'll upload it when the
submission tool is available again. If you still have comments, I always
appreciate it.

> 2141 <reserved> in the sub-namespace ID.

That's exactly the recommendation which is already described in section
2.11 of draft-dijkstra-urn-ogf.

> I suppose that this document should also be referenced in your Section 2.8.

Right now, I leave this process up to the OGF Technical Director, which
can subsequently describe this in a Grid Forum Document (GFD).

The reason not to refer to the GFD was a practical one. The plan is to
publish the GFD after publication of draft-dijkstra-urn-ogf. Hence, the
GFD does not have a identifier (GFD series number) yet, and thus could
not be referred to.

An alternative is to publish both documents simultaneously. An advantage
is that the reference becomes normative instead of informative.

I have no strong preference, but I'm willing to jump through a few loops
to publish them simultaneous. So the reference is now in, just to make
it slightly easier for whoever reads these things to find it :)

Regards,
Freek

---

From: Freek Dijkstra <[email-masked]>
Date: Mon, 25 Jul 2011 09:32:26 +0200

Mykyta Yevstifeyev wrote:

> Your new draft is certainly better.  I'll wait when it gets uploaded for 
> more careful reading and further comments, if any.

The draft submitter was available again this morning, so here it is:
http://tools.ietf.org/html/draft-dijkstra-urn-ogf-06

Mykyta and Peter, thanks for your feedback.

Mykyta, if you still see omissions or typos, please let me know shortly.

Peter, if you are still willing to sponsor this document, could you tell
me the procedure to push this document to the IESG/RFC Editor? I propose
to do this next week after the rush of this weeks IETF (Unfortunately, I
will not be present in Canada)

I'll ask for a provisional number for the GFD document, so the document
in the IETF and in the Open Grid Forum can be published simultaneously.

Regards,
Freek

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 25 Jul 2011 08:53:26 -0400

On 7/25/11 5:11 AM, Mykyta Yevstifeyev wrote:
> Freek,
> 
> The following are my minor/editorial comments.
> 
> Section 1:
> 
>>     This namespace specification is for a formal namespace.
> 
> This sentence is premature in Introduction.  You could better put it in
> the IANA considerations (see below).

I think that sentence is fine in the Introduction.

> Section 2.3:
> 
>>
>>    Technical Director
>>    Open Grid Forum
>>    P.O. Box 2326
>>    Joliet, Illinois 60434
>>    USA
>>    http://www.ogf.org/
>>    Email: [email-masked]
>>
>>    The position of technical director is currently fulfilled by Joel
>>    Replogle.
> 
> Does OGF Director has some email alias, as IETF Chair has
> ([email-masked])?  

[email-masked] seems to be an alias

> Also, this postal address (I mean PO Box 2326)
> actually refers to OGF Office
> (http://www.ogf.org/About/abt_contact.php); I don't think it's
> appropriate to include it here.

I see no problem with including it.

> Section 7:
> 
> I'd recommend to rewrite the section in the following way:
> 
>>     IANA is asked to register the "ogf" URN namespace identifier in
>>     the corresponding registry [URN-NAMESPACES] as "formal" [RFC3406]
>>     with reference to this document.
> 
> This is mostly the same as you currently have, but making 2
> improvements, (1) mentioning formal registration here, not in the
> Introduction, and (2) removing request to reference the website of OGF
> in the registry entry.

Seems fine.

> IMO, your document is ready for publication and am glad to hear that
> Peter agreed to sponsor it.

Yes, I'll do that.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 25 Jul 2011 09:10:48 -0400

> will not be present in Canada)

I've requested IETF Last Call.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Freek Dijkstra <[email-masked]>
Date: Mon, 25 Jul 2011 20:33:56 +0200

> [email-masked] seems to be an alias

It is. It is current forwarded to Joel Replogle.

>> Introduction, and (2) removing request to reference the website of OGF

I'm fine. Can I let the RFC editor handle this?
Otherwise I'll update as soon as I know the correct reference for the
Grid Forum Document.

> I've requested IETF Last Call.

Much obliged!

Freek

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 25 Jul 2011 06:07:27 +0300

Freek,

Mykyta

24.07.2011 23:06, Freek Dijkstra wrote:
>> it.  RFC 3986 restricts use of RFC 2141<reserved>  in any part of URI
>> 2141<reserved>  in the sub-namespace ID.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 25 Jul 2011 12:11:40 +0300

Freek,

([email-masked])?  Also, this postal address (I mean PO Box 2326) 

Section 7:

Mykyta Yevstifeyev