7. IANA Considerations
This document calls for two IANA registries: one for application
service tags, and one for application protocol tags.
IANA has established and will maintain a registry for S-NAPTR
Application Service Tags, listing at least the following information
for each such tag:
o Application Service Tag: A string conforming with the IANA-
registered-service defined in section 6.5.
o Defining publication: The RFC used to define the Application
Service Tag, as defined in the registration process, below.
An initial Application Service Tag registration is contained in [9].
IANA has established and will maintain a registry for S-NAPTR
Application Protocol Tags, listing at least the following information
for each such tag:
o Application Protocol Tag: A string conforming with the iana-
registered-protocol defined in section 6.5.
o Defining publication: The RFC used to define the Application
Protocol Tag, as defined in the registration process, below.
An initial Application Protocol Tag registration is defined in [10].
All application service and protocol tags that start with "x-" are
considered experimental, and no provision is made to prevent
duplicate use of the same string. Implementors use them at their own
risk.
All other application service and protocol tags are registered based
on the "specification required" option defined in [7], with the
further stipulation that the "specification" is an RFC (of any
category).
No further restrictions are placed on the tags except that they must
conform with the syntax defined below (Section 6.5).
The defining RFC must clearly identify and describe, for each tag
being registered,
o application protocol or service tag,
o intended usage,
o interoperability considerations,
o security considerations (see section 8 of this document for
further discussion of the types of considerations that are
applicable), and
o any relevant related publications.
