|
1.
|
Clear description of the referenced document:
|
|
|
|
|
2.
|
Status of approval:
|
|
|
Standards track document approved 2005-01. Also Known As STD 66.
|
|
3.
|
Justification for the specific reference:
|
|
|
This Recommendation | International Standard specifies an interoperable format for compression, transmission and storage of biomedical and general waveform signal data, and includes syntax and semantics for metadata and authentication-related information in the coded bitstream. In particular, the syntax element aust_key_source_uri is used to identify the provider of authentication key source information by means of a URI, and its semantics require use of the syntax and semantics specified in IETF Internet Standard 66.
A normative reference to RFC 3986 is necessary because RFC 3986 is the authoritative Internet Standard defining the generic syntax of Uniform Resource Identifiers. It specifies the common URI grammar, including the components and processing rules needed to parse URI references independently of individual URI schemes. Referencing RFC 3986 therefore ensures that URI-valued syntax elements in this Recommendation | International Standard are interpreted consistently by encoders, decoders and applications, and avoids defining a different or incompatible URI syntax within this specification.
The reference is also appropriate because the present Recommendation | International Standard does not define a new URI scheme or a new URI syntax. It only requires an existing, internationally deployed URI syntax to identify external resources or providers in a standardised way. The use of RFC 3986 avoids unnecessary duplication and ensures alignment with existing Internet, Web and application infrastructure.
Reason incorporation of the full text is inappropriate:
Incorporating the full text of RFC 3986 into this Recommendation | International Standard would be inappropriate. RFC 3986 is a complete Internet Standard covering the generic URI syntax, URI-reference resolution, normalisation and comparison, security considerations, IANA considerations and supporting appendices. Reproducing that material would substantially expand the Recommendation with content that is already maintained as a separate authoritative specification and would obscure the scope of the present waveform coding specification.
Full-text incorporation would also create unnecessary maintenance and consistency risks. Any duplicated extract of RFC 3986 could become inconsistent with the canonical RFC text or with future updates and interpretations in the IETF context. Since the Recommendation | International Standard only needs conformance to URI syntax and semantics, reference by citation is the technically correct and more maintainable approach.
Finally, the RFC Editor makes RFC 3986 available as the canonical source for the referenced Internet Standard, and the citation in the Recommendation identifies the document by title, RFC number, DOI and publication date. Implementers can therefore consult the authoritative specification directly without requiring its full reproduction in this Recommendation | International Standard.
Conclusion:
The normative reference to RFC 3986 is technically necessary, stable and appropriate, because URI-valued syntax elements in this Recommendation | International Standard depend on the generic URI syntax and semantics defined by that Internet Standard. Incorporation of the full RFC text is inappropriate because it would duplicate an independently maintained foundational specification, increase the size and editorial burden of this Recommendation | International Standard, and risk divergence from the authoritative source.
|
|
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 January 2005 (http://www.ietf.org/rfc/rfc3986.txt). The status is STANDARD.
|
|
6.
|
The degree of stability or maturity of the document:
|
|
|
Document published in January 2005 (http://www.ietf.org/rfc/rfc3986.txt). The status is STANDARD. Updated by RFC 6874, RFC 7320, RFC 8820. Obsoletes RFC 2732, RFC 1808, RFC 2396. Updates RFC 1738, Errata exist. Also Known As STD 66.
|
|
7.
|
Relationship with other existing or emerging documents:
|
|
|
URIs are widely used to identify resources.
|
|
8.
|
Any explicit references within that referenced document should also be listed:
|
|
|
Normative References/
[ASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986./
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997./
[STD63] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003./
[UCS] International Organization for Standardization, "Information Technology - Universal Multiple-Octet Coded Character Set (UCS)", ISO/IEC 10646:2003, December 2003./
/
Informative References/
[BCP19] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000./
[BCP35] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999./
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985./
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987./
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989./
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC 1535, October 1993./
[RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", RFC 1630, June 1994./
[RFC1736] Kunze, J., "Functional Recommendations for Internet Resource Locators", RFC 1736, February 1995./
[RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994./
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994./
[RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, June 1995./
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996./
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997./
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998./
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999./
[RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999./
[RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, "Guidelines for new URL Schemes", RFC 2718, November 1999./
[RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999./
[RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations", RFC 3305, August 2002./
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003./
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003./
[Siedzik] Siedzik, R., "Semantic Attacks: What's in a URL?", April 2001, http://www.giac.org/practical/gsec/Richard_Siedzik_GSEC.pdf./
|
|
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
|
|
