1. e-mail: Miguel.An.Garcia@nokia.com
AAA and AAAS URI
Miguel A. Garcia
draft-garcia-dime-aaa-uri-00.txt
IETF 66, DIME WG

2. Problem definition
RFC 3588 apparently defines the AAA and AAAS URI schemes,
"aaa://" FQDN [ port ] [ transport ] [ protocol ]
but they are buried in Section 4.3 Derived AVP formats
although this is not a problem
they are common for Diameter, Radius and Tacacs+
although RFC 3588 is about Diameter
Section 11 IANA considerations does not provide instructions to IANA to register these URI schemes,
therefore, IANA didn’t register them. See:
this is the problem

3. draft-garcia-dime-aaa-uri-00.txt
Started as a request to IANA to register the AAA URI originally defined in RFC 3588:
The document was originally drafted as an update RFC 3588.
This document was, at some point in the past, a WG item in AAA WG.
Pass a review in the URI-review list.
Pass WGLC in AAA WG.

4. draft-garcia-dime-aaa-uri-00.txt
On updating the document it was detected than an update was needed to make the URI definition compatible with RFC 2396 / RFC 3986.
The original definition created a hierarchical URI (aaa:// )
But AAA URIs are not hierarchical :
RFC 4395 (Registration of URI schemes say):
Avoid improper use of "//". The use of double slashes in the first part of a URI is not an artistic indicator that what follows is a URI: Double slashes are used ONLY when the syntax of the URI's <scheme-specific-part> contains a hierarchical structure as described in RFC In URIs from such schemes, the use of double slashes indicates that what follows is the top hierarchical element for a naming authority. (See Section 3.2 of RFC 3986 for more details.) URI schemes that do not contain a conformant hierarchical structure in their <scheme-specific-part> SHOULD NOT use double slashes following the "<scheme>:" string.
Some parts were underspecified.
‘FQDN’ is not formally defined -> apparently IP addresses are not allowed
No clear semantics to AAAS: “transport security used”.
No strategy for adding parameters to the URI.

5. What is next? Possible options: We don’t care, so we do nothing
Let’s hope none ever defines a AAA/AAAS URI scheme for another purpose.
We fix the IANA the AAA/AAAS URI scheme in a backwards compatible way, and we register with IANA.
Looks like a challenge... Not much margin for maneuver.
We register with IANA the AAA/AAAS URI scheme (with no changes towards RFC 3588) and work in a definition of a ‘diameter’ URI scheme that need not necessarily be backwards compatible with the AAA URI scheme.
Implicitly we would be deprecating the usage of AAA URIs in favor of the new ‘diameter’ URI scheme.
We register with IANA the AAA/AAAS URI scheme (with no changes towards RFC 3588).