|
1.
|
Clear description of the referenced document:
|
|
|
|
|
2.
|
Status of approval:
|
|
|
Informational RFC approved 2005-10.
|
|
3.
|
Justification for the specific reference:
|
|
|
This Recommendation | International Standard specifies an interoperable bitstream format for biomedical and general waveform signal coding and includes metadata-related syntax elements that can carry URI-based identifiers. In particular, the feature set syntax includes fs_label_uri as an alternative representation for feature labels, and the authentication start syntax includes aust_key_source_uri for identifying a provider or source of authentication-related information.
A reference to RFC 4151: The 'tag' URI Scheme is appropriate because that RFC defines the “tag” URI scheme, a URI scheme intended for identifiers that are unique across space and time and suitable for use as entity identifiers without requiring an authoritative resolution mechanism. This is relevant to the present Recommendation | International Standard because URI-valued fields may be used to carry identifiers for application-specific labels, metadata, providers, resources, or externally defined semantics, where a persistent identifier is needed but dereferenceable network access is not necessarily required. [rfc-editor.org],
The reference supports interoperability by ensuring that, when the “tag” URI scheme is used in URI-valued syntax elements, encoders, decoders and applications interpret such identifiers according to the same externally specified URI scheme. It also avoids the need for this Recommendation | International Standard to define a separate identifier scheme for non-resolvable or application-specific identifiers, thereby reducing the risk of incompatible private conventions.
Although RFC 4151: The 'tag' URI Scheme is identified as an Informational RFC and does not specify an Internet standard of any kind, it is the published IETF/RFC reference that describes the syntax and rules of the “tag” URI scheme. For that reason, it is suitable to reference it for the limited purpose of identifying and interpreting “tag” URIs where such URIs are used by this Recommendation | International Standard.
Reason incorporation of the full text is inappropriate:
Incorporation of the full text of RFC 4151: The 'tag' URI Scheme into this Recommendation | International Standard would be inappropriate. The present Recommendation | International Standard only needs to allow or reference use of the “tag” URI scheme in URI-valued fields; it does not need to reproduce the RFC’s full explanatory material, examples, discussion of tag syntax and rules, security considerations, IANA considerations, or references. [rfc-editor.org],
Full-text incorporation would also obscure the scope of this Recommendation | International Standard, which is waveform signal coding rather than URI scheme definition. The RFC is an independently published document in the IETF/RFC series, and implementers can consult the canonical RFC text directly. Reproducing the RFC text would create an unnecessary duplicate copy and could lead to inconsistencies if errata, clarifications or related updates are handled in the RFC context.
Furthermore, copying the full RFC text would add editorial burden without improving interoperability. The technical requirement for this Recommendation | International Standard is simply that any “tag” URI used in the relevant URI-valued syntax elements follows the scheme described by RFC 4151. Reference by citation is therefore the more precise and maintainable approach.
Conclusion:
The reference to RFC 4151 is justified because the “tag” URI scheme provides a recognised, published mechanism for creating persistent, non-resolvable URI identifiers that can be used in URI-valued syntax elements of this Recommendation | International Standard. Incorporation of the full RFC text is inappropriate because the RFC is an independently maintained, self-contained specification, while the present document only needs to rely on it by reference for the limited purpose of interpreting “tag” URIs.
|
|
4.
|
Current information, if any, about IPR issues:
|
|
|
Information on IPR issues regarding RFCs is available at: https://datatracker.ietf.org/ipr/search/. Specifically: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=3986
|
|
5.
|
Other useful information describing the "Quality" of the document:
|
|
|
Document published in October 2005 (http://www.ietf.org/rfc/rfc4151.txt). The status is INFORMATIONAL.
|
|
6.
|
The degree of stability or maturity of the document:
|
|
|
Document published in October 2005 (http://www.ietf.org/rfc/rfc4151.txt). The status is INFORMATIONAL. Errata exist.
|
|
7.
|
Relationship with other existing or emerging documents:
|
|
|
URIs are widely used to identify resources. Tag URIs are distinct from most other URIs in that they have no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources.
|
|
8.
|
Any explicit references within that referenced document should also be listed:
|
|
|
Normative References/
/
[1] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform/
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,/
January 2005./
/
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax/
Specifications: ABNF", RFC 2234, November 1997./
/
[3] Mockapetris, P., "Domain names - implementation and/
specification", STD 13, RFC 1035, November 1987./
/
[4] "Data elements and interchange formats -- Information/
interchange -- Representation of dates and times", ISO/
(International Organization for Standardization) ISO 8601:1988,/
1988./
/
Informative References/
/
[5] Leach, P. and R. Salz, "UUIDs and GUIDs", Work in Progress,/
1997./
/
[6] "Information technology - Open Systems Interconnection - Remote/
Procedure Call (RPC)", ISO (International Organization for/
Standardization) ISO/IEC 11578:1996, 1996./
/
[7] "Specification of abstract syntax notation one (ASN.1)", ITU-T/
recommendation X.208, (see also RFC 1778), 1988./
/
[8] Mealling, M., "A URN Namespace of Object Identifiers",/
RFC 3061, February 2001./
/
[9] Paskin, N., "Information Identifiers", Learned Publishing Vol./
10, No. 2, pp. 135-156, (see also www.doi.org), April 1997./
/
[10] Klyne, G. and C. Newman, "Date and Time on the Internet:/
Timestamps", RFC 3339, July 2002.
|
|
9.
|
Qualification of
ISOC/IETF:
|
|
|
9.1-9.6 Decisions of ITU Council to admit ISOC to participate in the work of the Sector (June 1995 and June 1996).
9.7 The Internet Engineering Steering Group (IESG) is responsible for ongoing maintenance of the RFCs when the need arises. Comments on RFCs and corresponding changes are accommodated through the existing standardization process.
9.8 Each revision of a given RFC has a different RFC number, so no confusion is possible. All RFCs always remain available on-line. An index of RFCs and their status may be found in the IETF archives at http://www.rfc-editor.org/rfc.html.
|
|
10.
|
Other (for any supplementary information):
|
|
|
None
|
|
