Detailed comment on URIs

207-218 See example of how the full use of a URI is described in Web Sockets:
Quoting:
The term "URI" is used in this document as defined in [RFC3986].

When an implementation is required to send data as part of the
WebSocket Protocol, the implementation MAY delay the actual
transmission arbitrarily, e.g., buffering data so as to send fewer IP
packets.

Note that this document uses both [RFC5234] and [RFC2616] variants of
ABNF in different sections.

This specification defines two URI schemes, using the ABNF syntax
defined in RFC 5234 [RFC5234], and terminology and ABNF productions
defined by the URI specification RFC 3986 [RFC3986].

ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]

host = <host, defined in [RFC3986], Section 3.2.2>
port = <port, defined in [RFC3986], Section 3.2.3>
path = <path-abempty, defined in [RFC3986], Section 3.3>
query = <query, defined in [RFC3986], Section 3.4>

The port component is OPTIONAL; the default for "ws" is port 80,
while the default for "wss" is port 443.

The URI is called "secure" (and it is said that "the secure flag is
set") if the scheme component matches "wss" case-insensitively.

The "resource-name" (also known as /resource name/ in Section 4.1)
can be constructed by concatenating the following:

o "/" if the path component is empty

o the path component

o "?" if the query component is non-empty

o the query component

Fragment identifiers are meaningless in the context of WebSocket URIs
and MUST NOT be used on these URIs. As with any URI scheme, the
character "#", when not indicating the start of a fragment, MUST be
escaped as %23.

1. The components of the WebSocket URI passed into this algorithm
(/host/, /port/, /resource name/, and /secure/ flag) MUST be
valid according to the specification of WebSocket URIs specified
in Section 3. If any of the components are invalid, the client
MUST Fail the WebSocket Connection and abort these steps.

Notice that the result is clearer, and easier to code to. The commenter is not suggesting* these are the oBIX rules, merely stating that a form similar to this would be better for declaring what is expected.