IANA u-NAPTR considerations from rfc 4848

Hi BDXers,

One thing that needs consensus for the little metadata service location specification is  handling which NAPTR field values for the Service field might need registration.

Sander suggested that both metadata service location records and registration service location records be published. If so, and we agree to define values for CPPA and SML, we would define 4 values.

So next consider the IANA section from RFC 4848 that discusses “U-NAPTR”


5.  IANA Considerations

   This document does not itself place any requirements on IANA, but
   provides the basis upon which U-NAPTR-using services can make use of
   the existing IANA registries for application service tags and
   application protocol tags (defined in RFC 3958 [2]).

   As is the case for S-NAPTR, 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.  Use them at your
   own risk.

   All other application service and protocol tags are registered based
   on the "specification required" option defined in [6], with the
   further stipulation that the "specification" is an RFC (of any
   category).

   There are no further restrictions placed on the tags other than that
   they must conform with the syntax defined above (Section 4.5).

[This section provides an ABNF for service—we will certainly want to conform.]

   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 6 of this document for
      further discussion of the types of considerations that are
      applicable)

   o  Any relevant related publications

   The defining RFC may also include further application-specific
   restrictions, such as limitations on the types of URIs that may be
   returned for the application service.


I think that an OASIS standard would count as enough like an RFC to be acceptable.
Not sure about whether an OASIS committee specification would do it.
We could put that out as an independent RFC draft (informational or experimental track probably.)
Need to check with OASIS about this.