Subject: [Uri-review] Request for review of new ipn: URI scheme

From: Elwyn Davies <[email-masked]>
Date: Wed, 16 Feb 2011 18:41:10 +0000

Hi.

The DTN Research Group has a draft being examined by the IESG for
approval as an Experimental RFCthat contains the specification of the
ipn: URI scheme:
http://tools.ietf.org/html/draft-irtf-dtnrg-cbhe-08

We would like to request review of the scheme prior to approval of the
draft.

The original motivation for the definition of this scheme is usage of
DTNs in space-based networks where bandwidth is at a premium, but its
usage is not confined to theis application.

It has been observed by the responsible AD that the ABNF syntax in the
draft is faulty (it uses ':=' rather than '=' throughout.. it will be
replaced with:

ipn-uri       = "ipn:" ipn-hier-part
ipn-hier-part = node-nbr nbr-delim service-nbr ; a path-rootless
node-nbr      = 1*DIGIT
nbr-delim     = "."
service-nbr   = 1*DIGIT

We also need to specify the References for the scheme - the only
relevant reference is the defining draft, which will hopefully be an
experimental RFC shortly.

Regards,
Elwyn Davies
Document Shepherd

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 16 Feb 2011 22:38:16 +0200

Hello Elwyn,

Here are some comments to the 'ipn' URI scheme registration template - 
see in-line.

> 4. IANA Considerations
>
>    Registration of the "ipn" URI scheme is requested as follows.
Here the Informative reference to RFC 4395 might be acceptable.
>    URI scheme name: "ipn".
>    Status: provisional.
I wonder why it is Provisional.  Provisional means 'not complete and 
acceptable specification' while this is not such case.  I suggest Permanent.
>
>    URI scheme syntax:
>
>    This specification uses the Augmented Backus-Naur Form (ABNF)
>    notation of [RFC2234], including the core ABNF syntax rule for DIGIT
>    defined by that specification.
Why RFC 2234 - it is obsoleted by RFC 4234 and RFC 5234 - the most 
current doc.  Moreover, I am not able to find any reference in the 
corresponding section of the draft to any of the documents.  If you 
accept RFC 5234, the rule definition must be rule=def but not rule:=def.
>
>    o  ipn-uri := "ipn:" ipn-hier-part
>
>    o  ipn-hier-part := node-nbr nbr-delim service-nbr ; a path-rootless
This rule is not acceptable at all.  I do not know what you mean, but 
'node-nbr nbr-delim service-nbr' is already path-rootless; moreover what 
are 'a' and ';' rules, that are not defined at all.  You might have 
meant "a" and ";" but I am not sure for this and other concerns I've 
told about above.  I'd like you clarify this syntax.
>
>    o  node-nbr := 1*DIGIT
>
>    o  nbr-delim := "."
>
>    o  service-nbr := 1*DIGIT
>
>    None of the reserved characters defined in the generic URI syntax are
>    used as delimiters within URIs of the IPN scheme.
>
>    URI scheme semantics: URIs of the IPN scheme are used as endpoint
>    identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol
>    (BP) [RFC5050] as described in 2.1 above.
>
>    Encoding considerations: URIs of the IPN scheme are encoded
>    exclusively in US-ASCII characters.
Here I'd propose the better variant: "generic encoding considerations 
for URI schemes, defined in Section 2 of [RFC3986], concern 'ipn' one as 
well.  Non-ASCII characters are to be mapped as defined in Section 3.1 
of RFC 3987 [RFC3987]" with the Normative reference of RFC 3987.

>
>    Applications and/or protocols that use this URI scheme name: the
>    Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050].
>
>    Interoperability considerations: as noted above, URIs of the IPN
>    scheme are encoded exclusively in US-ASCII characters.
This is not Interoperability considerations - you'd better omit this 
point in the template at all.
>
> [...]
>
>    Contact: Scott Burleigh, Jet Propulsion Laboratory, California
>    Institute of Technology, [email-masked], +1 (800) 393-
>    3353.
>
>    Author/Change controller.  Scott Burleigh, Jet Propulsion Laboratory,
>    California Institute of Technology, [email-masked], +1
>    (800) 393-3353.
I'd like you, as the doc. shepherd, bring these comments to the authors' 
attention.

Mykyta Yevstifeyev

16.02.2011 20:41, Elwyn Davies wrote:
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Feb 2011 13:02:55 +0000

> Hello Elwyn,

Hi Mykyta,

> Here the Informative reference to RFC 4395 might be acceptable.

+1.

> acceptable specification' while this is not such case.  I suggest 

Provisional is also frequently used for something that needs to be 
registered, but that might not be quite stable.
I don't have a strong opinion on whether this particular URI scheme 
should be provisional or permanent, but I note that the "dtn" URI scheme 
(which is closely related to this one) is Provisional.

> accept RFC 5234, the rule definition must be rule=def but not rule:=def.

+1.

> 'node-nbr nbr-delim service-nbr' is already path-rootless; moreover 
> what are 'a' and ';' rules, that are not defined at all.  You might 
> have meant "a" and ";" but I am not sure for this and other concerns 
> I've told about above.  I'd like you clarify this syntax. 

Here I disagree. Everything after ";" is a comment. An ABNF comment can 
appear at the end of a line. So I think this is a valid ABNF rule 
(modulo use of ":=").

> for URI schemes, defined in Section 2 of [RFC3986], concern 'ipn' one 
> as well.  Non-ASCII characters are to be mapped as defined in Section 
> 3.1 of RFC 3987 [RFC3987]" with the Normative reference of RFC 3987.

Considering that the current ABNF doesn't use anything but US-ASCII, I 
think the current text is actually better.

> point in the template at all.

I think RFC 4395 mentions "encodings" as a possible thing to discuss in 
this section.

> I'd like you, as the doc. shepherd, bring these comments to the 
> authors' attention.

 [...]
 
Best Regards,
Alexey

-- 
IETF Application Area Director, <http://www.ietf.org/iesg/members.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 18 Feb 2011 15:21:52 +0200

> appear at the end of a line. So I think this is a valid ABNF rule

Now I agree - I just did not notice that was the comment.

> think the current text is actually better.

In this case you should have the normative reference to ASCII
standard, that RFC 3986 already has.

>>>    California Institute of Technology, [email-masked], +1

I would also like to propose to change these to IRSG and IRTF,
respectively, as it is done for IETF-stream RFCs' regsitrations (here
we have IESG and IETF).

All the best,
Mykyta Yevstifeyev

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 18 Feb 2011 09:23:45 -0700

> respectively, as it is done for IETF-stream RFCs' regsitrations (here

That does seem sensible (I noticed it too during my review), but I'm not
sure what IRTF policy is.

Peter

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

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 19 Feb 2011 17:22:46 +0000

[...]

>standard, that RFC 3986 already has.
Sure.

>respectively, as it is done for IETF-stream RFCs' regsitrations (here
Probably sensible, I will double check with IRTF people.

---

From: Graham Klyne <[email-masked]>
Date: Sun, 20 Feb 2011 18:17:27 +0000

> (which is closely related to this one) is Provisional.

To my mind, "provisional" means not ready for garnering community consensus, 
which can be for many reasons, including those mentioned.

The intended-status of the document is experimental, so I think provisional is 
right for the scheme registration.  The bar for registration as permanent would 
need to be considerably higher; I guess the group behind this work are not yet 
ready to jump through those hoops.

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Sun, 20 Feb 2011 18:26:53 +0000

> sure what IRTF policy is.

Hmmm... I'm not so sure.

For IETF-stream documents, we know there's a working group, or the IETF list, 
for sending comments to.  In the case of IRTF-stream documents, I'm not sure 
where comments should be directed.

As for change control, then IRSG/IRTF may be appropriate if this is the result 
of a community process than can be carried by multiple particpants.  Thus, I 
guess it depends on how the IRTF works in these matters.

#g
--