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.

bdxr message