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

[<[e-mail]>]

Alfred,

thanks for your detailed comments; I've attached a
drafty draft including your proposed changes.

That's a very good point on the recursive definition; I've
gotten around it by

extended-scheme = scheme [][][][][]
(decently laid out)

which is intended to be clear to the reader, though the
formal correctness of this retrofitting of punctuation pairs
within the scheme definition is, as you point out, difficult
to achieve.

Many thanks!

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[e-mail]>


--- On Wed, 28/10/09, Alfred Hönes <[e-mail]> wrote:

> From: Alfred Hönes <[e-mail]>
> Subject: draft-wood-tae-specifying-uri-transports-07
> To: [e-mail]
> Cc: [e-mail]
> Date: Wednesday, 28 October, 2009, 10:52
> 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:  [e-mail] 
>                
>    |
> +------------------------+--------------------------------------------+
> 
>