Re: [art] [Uri-review] Re: Alternative representation of URIs in YANG

Trying to move this issue toward a consensus...

I've looked again at the 6 messages I've seen on this (including my
own).  There seems to be some concern that the proposed Yang "grouping"
in draft-ietf-netconf-http-client-server-30.txt can't support the full
generality of URIs.  But as far as I can tell (after having the
subtleties of Yang explained to me), the proposal can support all URIs.

As described by a message from Kent and the tree diagram in the I-D:

     grouping uri:
       +-- scheme       string
       +-- authority!
       |  +-- userinfo?   string
       |  +-- host        inet:host
       |  +-- port?       inet:port-number
       +-- path?        string
       +-- query?       string
       +-- fragment?    string

There's a subtlety that the items marked with ? or ! can be either
present or absent in the Yang XML data object.

And I've not seen anyone propose a particular URI that can't be parsed
into the draft-ietf-netconf-http-client-server-30.txt format using a
straightforward application of the ABNF in RFC 3986.

I notice that in the simple uri typedef in RFC 6991, the description
includes this text:

         Objects using the uri type MUST be in US-ASCII encoding,
         and MUST be normalized as described by RFC 3986 Sections
         6.2.1, 6.2.2.1, and 6.2.2.2.  All unnecessary
         percent-encoding is removed, and all case-insensitive
         characters are set to lowercase except for hexadecimal
         digits, which are normalized to uppercase as described in
         Section 6.2.2.1.

It's possible that the I-D may want to require some of this
normalization.  But that decision doesn't seem to affect the validity of
this representation of URIs.

Also, it's conceivable that this representation may be valid but have
other infelicities.  If anyone know of those, could they please speak
up?

If there are no unresolved problems, can please we explicitly declare
that the I-D is OK in regard to these problems?

Dale

Received on Tuesday, 16 December 2025 03:23:19 UTC