NAM — Naming FTF / RFC2396 Compliance Issue

I have one issue with the naming FTF Sept 9th doc
concerning RFC2396. I would like an issue number to
be assigned to this. (This post has already appeared
in a slightly different form on the naming_ftf list).

I am extremeley reluctant to suggest further changes to the URL
at this point but feel the issue has to be considered.

Fortunately, the suggested changes to the URL forms are
small.

1. RFC2396 Compliance:
I received some email from some individuals that are a bit
more URI "aware" than I, pointing out
that in 2396:
a. URI's that start out <scheme>:/ have to follow
one set of rules (hier_part URIs), those that don't
start with a leading "/" after the scheme are
free to do what they'd like (opaque part URIs).

The details are in the first paragraphs of
chapter 3 of 2396.

b. Our use of "//" as a familiar shorthand for
iiop, will put corbaloc/corbaname in the
restricted hier_part category, with a likely
disapproval from IANA. (For any number of
reasons, multiple <authority>'s, <authority>'s
using different transports, non-hierarchial keys...)

c. If we were to remove the shorthand "//" for iiop and
allow "" as well as "iiop" for the iiop protocol id,
we would be compliant and have URLs like:

corbaloc::xyz.com/a/b/c
corbaname::xyz.com,atm:2452r2f34f/aContext#a/b/c

d. For discussion purposes, I have attached a BNF file describing
corbaloc / corbaname in the same style as the BNF in Appendix A of
2396. In it, I have broken out "//" as a seperate token:
iiop_id_reserved_2396. (BNF at bottom of email)

e. Possible courses of action:
We can:
1. leave "//" and hope IANA won't object or simply do
not register the schemes.
2. remove "//" and use "" for iiop
3. support "", leave "//" with a footnote indicating
that it may be deprecated, depending on IANA
approval.

RFC2396 compliance is desirable. Agreed to change the iiop protocol shorthand from "//" to ":".