[Uri-review] draft-wood-tae-specifying-uri-transports-07

Alfred Hönes <ah@TR-Sys.de> Wed, 28 October 2009 10:52 UTC

Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: uri-review@core3.amsl.com
Delivered-To: uri-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4FE43A6784 for <uri-review@core3.amsl.com>; Wed, 28 Oct 2009 03:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.919
X-Spam-Level: *
X-Spam-Status: No, score=1.919 tagged_above=-999 required=5 tests=[AWL=0.668, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
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 fNYUEJbWvWZu for <uri-review@core3.amsl.com>; Wed, 28 Oct 2009 03:52:48 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 6015A3A659C for <uri-review@ietf.org>; Wed, 28 Oct 2009 03:52:47 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA023277133; Wed, 28 Oct 2009 11:52:13 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id LAA02998; Wed, 28 Oct 2009 11:52:11 +0100 (MEZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <200910281052.LAA02998@TR-Sys.de>
To: L.Wood@society.surrey.ac.uk
Date: Wed, 28 Oct 2009 11:52:11 +0100
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 8bit
Cc: uri-review@ietf.org
Subject: [Uri-review] draft-wood-tae-specifying-uri-transports-07
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2009 10:52:49 -0000

Hello,
I've followed up to your updated Internet-Draft,
draft-wood-tae-specifying-uri-transports-07, and would like
to submit a few (mostly) editorial comments.


(1)  Section 2 -- general

This section is so long that it becomes tedious to point to
particular text in it.  Maybe structuring it into sub-sections
would help.


(2)  Section 2 -- syntax definition

The integration of the new syntax with RFC 3986 is difficult,
since the rule name <scheme> from RFC 3986 is made use of in
all modern specifications of URI Schemes.

The draft specifies:

   scheme = scheme [ "-+" port behaviour ] [ "++" transport ] ["+-"
   interface ] [ "--" dynamic configuration]

At first glance, it looks like there were distinct tokens
"port", "behavior", "dynamic", and "configuration".
For clarity, I recommend to join the word pairs using hyphens.
Further, the visual appearance of the syntax rule would be
improved substantially by matching the line break with the
logical structure and using indentation:

   scheme = scheme [ "-+" port-behaviour ] [ "++" transport ]
                   [ "+-" interface ] [ "--" dynamic-configuration ]

In this prsentation form, however, it becomes apparent that this
rule is recursive; that would essentially allow repeating the
new suffix elements in any number and order, which you apparently
do not want.
My initial idea to fix that,

   scheme       = basic-scheme
                  [ "-+" port-behaviour ] [ "++" transport ]
                  [ "+-" interface ] [ "--" dynamic-configuration ]

   basic-scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
                ; <scheme> in RFC 3986

... makes integration with existing URI Scheme definitions cumbersome;
there seems no easy way to do that in a formally correct manner;
maybe this integrated alternative would be slightly better (yet not
satisfactorily):

   scheme   =/ ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
                    ; <scheme> definition in RFC 3986
               [ "-+" port-behaviour ] [ "++" transport ]
               [ "+-" interface ] [ "--" dynamic-configuration ]

Another possibility with less ambiguities:

   scheme                =/ basic-scheme
                           [ "-+" port-behaviour ]
                           [ "++" transport ]
                           [ "+-" interface ]
                           [ "--" dynamic-configuration ]

   basic-scheme          = scheme-token
                           ; any IANA-registered URI Scheme name

   port-behaviour        = scheme-token
   transport             = scheme-token
   interface             = scheme-token
   dynamic-configuration = scheme-token

   scheme-token          = ALPHA *( [ "+" / "-" / "." ] (ALPHA / DIGIT) )


(3)  Section 2 -- referal to DNS

The single DNS based mechanism containing service information down
to the port level I am aware of is the SRV Resource Record (RR).
Therefore, it might be better to modify:

   The optionally-included "--" gets configuration information and
|  transport/services to use dynamically via some method, e.g.  DNS
|  records, but can be partly overriden by other locally-provided
   configuration from the other three modifier types described above.
---
   The optionally-included "--" gets configuration information and
|  transport/services to use dynamically via some method (e.g., via DNS
|  SRV records), but can be partly overriden by other locally-provided
   configuration from the other three modifier types described above.

With "via", the proposed phrase implicitly also comprises DNS-based
DDDS using NAPTR RRs (RFC 3403 et al.).


(4)  Section 3, 3rd para -- language

I suggest to improve the grammar:

   ... has proposed using ... and could indicates ...
---                               ^^^^^^^^^^^^^^^
   ... has proposed using ... and indicating ...

I.e., with the full context:

   [I-D.jennings-http-srv] has proposed using DNS lookup of a SRV record
   to return a dynamic port value, as well as an address, and could
   indicates this using http--srv:// and http--srv:// in line with the
   use of a service name as indicated above.
---
   [I-D.jennings-http-srv] has proposed using DNS lookup of a SRV record
|  to return a dynamic port value, as well as an address, and indicating
   this using http--srv:// and http--srv:// in line with the use of a
   service name as indicated above.


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