bdxr — archive

[Dale Moberg]

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.