-1Question(s):
28/16
Study Group: 16
Meeting, date:
Working Party:
2/16 Intended type of document(R-C-D-TD):
TD
Source:
Title:
A.5 justification information for draft revised H.810
Contact:
<Name>
<Organization>
<Country>
Contact:
Tel:
Fax:
Email:
Tel:
Fax:
Email:
Please don't change the structure of this table, just insert the necessary information.
1
Introduction
According to ITU procedures, as described in ITU-T Recommendation A.5, any normative
reference to documentation produced outside the ITU (other than ISO and IEC texts) needs to be
evaluated by the study group or working party before a decision is made to incorporate the
reference in an ITU-T Recommendation.
This TD contains the A.5 justification information for revised H.810.
2
Referred documents and respective justifications
- Bluetooth BCS: Bluetooth SIG, Body Composition Service, Version 1.0
- Specification approved at 2014-10-21.
- The Body Composition Service, Version 1.0, is needed to allow device inter-connectivity within
the ITU-T H.810 personal area network architecture. This specification defines a short-range
communications system intended to replace the cable(s) connecting portable and/or fixed
electronic devices for body composition analyzer.
- Complete A.5 justification information can be found in Annex 1.
- Bluetooth CTS: Bluetooth SIG, Current Time Service, Version 1.1
- Specification approved at 2014-10-07.
- The Current Time Service, Version 1.1, is needed to allow device inter-connectivity within the
ITU-T H.810 personal area network architecture. This specification defines how a Bluetooth
device can expose date and time information to other Bluetooth devices.
- Complete A.5 justification information can be found in Annex 2.
- Bluetooth PHDT v1.5: Bluetooth SIG, Personal Health Devices Transcoding White Paper, v1.5
- Specification approved at 2014-10-21.
- The Bluetooth Personal Health Devices Transcoding White Paper, v1.5, is needed to allow
device inter-connectivity within the Continua Design Guidelines personal area network
architecture. This specification defines a short-range communications system intended to
replace the cable(s) connecting portable and/or fixed electronic devices for Bluetooth low
energy sensors.
-2- Complete A.5 justification information can be found in Annex 3.
- GSM/UMTS: ETSI TS 123 040 V11.3.0 (2012-10), Digital cellular telecommunications system
(Phase 2+);Universal Mobile Telecommunications System (UMTS); Technical realization of the
Short Message Service (SMS). (3GPP TS 23.040 version 11.3.0 Release 11)
- Specification approved at 2012-10.
- The ITU-T H.810 architecture uses Short Message Service (SMS) to provide a means of
sending messages of limited size to and from GSM/UMTS/EPS mobiles.
- Complete A.5 justification information can be found in Annex 4.
- HL7 CDA CD: HL7 Implementation Guide for Clinical Document Architecture, Release 2:
Consent Directives, Release 1
- Approved by HL7 as a Draft Standard for Trial Use (DSTU) in 2011-01.
- The ITU-T H.810 architecture uses HL7 Implementation Guide for Clinical Document
Architecture, Release 2 (HL7 CDA CD). The purpose of this document is to describe constraints
on the Clinical Document Architecture Release 2 (CDA R2) header and body elements used to
express Privacy Consent Directive documents.
- Complete A.5 justification information can be found in Annex 5.
- HL7 CDA QFD (2014): HL7 Implementation Guide for CDA, Release 2: Questionnaire Form
Definition Document, Release 1
- Approved by HL7 as a Draft Standard for Trial Use (DSTU) in 2014-01-31.
- The ITU-T H.810 architecture uses HL7 CDA: Questionnaire Form Definition Document (HL7
CDA QFD). This document describes constraints on the Clinical Document Architecture (CDA)
Release 2 (R2) header and body elements of Questionnaire Form Definition documents. The
purpose of a Questionnaire Form Definition document is to capture the health survey questions
or question sets to be administered to a patient. Questionnaire Form Definition documents
enable the definition of questions for surveying the patient's perceptions on their health and the
impact that any treatments or adjustments to lifestyle have had on their quality of life.
- Complete A.5 justification information can be found in Annex 6.
- HL7 CDA QRD (2014): HL7 Implementation Guide for CDA, Release 2: Questionnaire Response
Document, Release 1
- Approved by HL7 as a Draft Standard for Trial Use (DSTU) in 2014-01-31.
- The ITU-T H.810 architecture uses HL7 CDA: Questionnaire Response Document (HL7 CDA
QFD). This document describes constraints on the Clinical Document Architecture (CDA)
Release 2 (R2) header and body elements of Questionnaire Response documents. The purpose
of a Questionnaire Response document is to capture the health survey answers or answer sets to
questions that have been administered to a patient. Questionnaire Response documents enable
the capture of responses for surveying the patient's perceptions on their health and the impact
that any treatments or adjustments to lifestyle have had on their quality of life.
- Complete A.5 justification information can be found in Annex 7.
- HL7 RLUS (2013): Health Level 7 Service Functional Model Specification - Retrieve, Locate, and
Update Service (RLUS), Release 1
- Approved by HL7 as a Draft Standard for Trial Use (DSTU) in 2013-03-22.
- The ITU-T H.810 architecture uses HL7 Retrieve, Locate, and Update Service (RLUS) Service
-3Functional Model. The RLUS Service Functional Model specify the appropriate capabilities that
must be realized by a service interface to locate, retrieve, and update resources (e.g. documents,
messages) among and within healthcare organizations.
- Complete A.5 justification information can be found in Annex 8.
- IETF RFC 2818 (2000): HTTP Over TLS, May 2000
- This is an IETF Informational RFC, published in May 2000. Errata exist.
- [INFORMATIONAL RFC] The ITU-T H.810 requires the use of HTTP over TLS for the
operation of medical, health and fitness devices using the WAN interface specifically for its
privacy cryptography for data encryption and its connection reliability and integrity using secure
hash functions. The HTTP over TLS provides use TLS to secure HTTP connections over the
Internet.
- Complete A.5 justification information can be found in Annex 9.
- IETF RFC 4346 (2006): The Transport Layer Security (TLS) Protocol, Version 1.1, April 2006
- Proposed Standard. Obsoleted by RFC 5246.
- [OBSOLETED] The ITU-T H.810 requires the use of TLS v1.1 for the operation of medical,
health and fitness devices using the WAN interface specifically for its privacy cryptography for
data encryption and its connection reliability and integrity using secure hash functions. The
TLS v1.1 protocol provides sufficient communication privacy over the Internet allowing
client/server applications to communicate in a way that is designed to prevent eavesdropping,
tampering, or message forgery. There is also dependency on the use of this spec across other
IHE and HL7 that also use this version of the TLS protocol.
- Complete A.5 justification information can be found in Annex 10.
- IETF RFC 6749 (2012): The OAuth 2.0 Authorization Framework
- Specification approved at 2012-10.
- The ITU-T H.810 requires the use of OAuth 2.0 Authorization Framework for web services
security. The OAuth 2.0 authorization framework enables a third-party application to obtain
limited access to an HTTP service, either on behalf of a resource owner by orchestrating an
approval interaction between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf.
- Complete A.5 justification information can be found in Annex 11.
- IETF RFC 6750 (2012): The OAuth 2.0 Authorization Framework: Bearer Token Usage
- Specification approved at 2012-10.
- The ITU-T H.810 architecture uses bearer tokens in HTTP requests to access OAuth 2.0
protected resources. Any party in possession of a bearer token (a "bearer") can use it to get
access to the associated resources (without demonstrating possession of a cryptographic key).
- Complete A.5 justification information can be found in Annex 12.
- OASIS MQTT (2013): OASIS MQTT Version 3.1.1
- Specification approved 2013-12-12.
-4- The ITU-T H.810 architecture uses OASIS MQTT. The MQTT is a Client Server
publish/subscribe messaging transport protocol.
- Complete A.5 justification information can be found in Annex 13.
- TIA-637-C: TIA-637-C, Short Message Service (SMS) For Wideband Spread Spectrum Systems
- Historical specification approved at 2012-11. Transposition of 3GPP2 C.S0015-C v1.0.
Superseded by revision D.
- The ITU-T H.810 architecture uses Short Message Service (SMS) to provide a means of
sending messages of limited size to and from GSM/UMTS/EPS mobiles.
- Complete A.5 justification information can be found in Annex 14.
- ZigBee Spec: Zigbee Alliance, ZigBee Specification, January 17, 2008
- Specification approved at 2008-01-17.
- The ZigBee Specification is needed to allow device inter-connectivity within the ITU-T H.810
personal area network architecture. It enhances the IEEE 802.15.4 standard by adding network
and security layers and an application framework.
- Complete A.5 justification information can be found in Annex 15.
-5-
Annex 1
A.5 justification information for the reference to Bluetooth BCS
1
Clear description of the referenced document:
Bluetooth BCS: Bluetooth SIG, Body Composition Service, Version 1.0
2
Status of approval:
Specification approved at 2014-10-21.
3
Justification for the specific reference:
The Body Composition Service, Version 1.0, is needed to allow device inter-connectivity within the
ITU-T H.810 personal area network architecture. This specification defines a short-range
communications system intended to replace the cable(s) connecting portable and/or fixed electronic
devices for body composition analyzer.
4
Current information, if any, about IPR issues:
N/A
5
Other useful information describing the "Quality" of the document:
Specification approved at 2014-10-21 and some qualified devices implementing this version of the
specification exist.
6
The degree of stability or maturity of the document:
See item 5 above.
7
Relationship with other existing or emerging documents:
See item 5 above.
8
Any explicit references within that referenced document should also be listed:
[1] Bluetooth Core Specification v4.0 or later version of the Core Specification.
[2] Characteristic and Descriptor descriptions are accessible via the Bluetooth SIG Assigned
Numbers.
[3] Current Time Service Specification v1.1 or later
[4] IEEE 11073-10420 - 2010 (Health informatics-Personal health device communication - Part
10420: Device specialization - Body Composition Analyzer)
-69
Qualification of Bluetooth:
Bluetooth SIG meets the qualifying criteria for normative referencing as per Recommendation ITUT A.5.
10
N/A
Other (for any supplementary information):
-7-
Annex 2
A.5 justification information for the reference to Bluetooth CTS
1
Clear description of the referenced document:
Bluetooth CTS: Bluetooth SIG, Current Time Service, Version 1.1
2
Status of approval:
Specification approved at 2014-10-07.
3
Justification for the specific reference:
The Current Time Service, Version 1.1, is needed to allow device inter-connectivity within the ITUT H.810 personal area network architecture. This specification defines how a Bluetooth device can
expose date and time information to other Bluetooth devices.
4
Current information, if any, about IPR issues:
N/A
5
Other useful information describing the "Quality" of the document:
Specification approved at 2014-10-07 and some qualified devices implementing this version of the
specification exist.
6
The degree of stability or maturity of the document:
See item 5 above.
7
Relationship with other existing or emerging documents:
See item 5 above.
8
Any explicit references within that referenced document should also be listed:
[1] Bluetooth Core Specification v4.0 or later
[2] Characteristic and Descriptor descriptions are accessible via the Bluetooth SIG Assigned
Numbers: <http://www.bluetooth.org/Technical/AssignedNumbers/home.htm>
9
Qualification of Bluetooth:
Bluetooth SIG meets the qualifying criteria for normative referencing as per Recommendation ITUT A.5.
10
N/A
Other (for any supplementary information):
-8-
Annex 3
A.5 justification information for the reference to Bluetooth PHDT v1.5
1
Clear description of the referenced document:
Bluetooth PHDT v1.5: Bluetooth SIG, Personal Health Devices Transcoding White Paper, v1.5
2
Status of approval:
Specification approved at 2014-10-21.
3
Justification for the specific reference:
The Bluetooth Personal Health Devices Transcoding White Paper, v1.5, is needed to allow device
inter-connectivity within the Continua Design Guidelines personal area network architecture. This
specification defines a short-range communications system intended to replace the cable(s)
connecting portable and/or fixed electronic devices for Bluetooth low energy sensors.
4
Current information, if any, about IPR issues:
N/A
5
Other useful information describing the "Quality" of the document:
Specification approved at 2014-10-21 and some qualified devices implementing this version of the
specification exist.
6
The degree of stability or maturity of the document:
See item 5 above.
7
Relationship with other existing or emerging documents:
See item 5 above.
8
Any explicit references within that referenced document should also be listed:
[1]
ISO/IEEE Std 11073-20601- 2008 Health Informatics - Personal Health Device
Communication - Application Profile - Optimized Exchange Protocol - version 1.0.This
also includes ISO/IEEE Std 11073-20601a™-2010 – Amendment 1
[2]
Device Information Service v1.1
[3]
Bluetooth SIG Assigned
Numbers.<http://www.bluetooth.org/Technical/AssignedNumbers/home.htm>
[4]
ISO/IEEE Std 11073-10408-2008 Standard for Health informatics - Personal health device
communication - Device specialization - Thermometer
[5]
Health Thermometer Service v1.0
-9[6]
Continua Design Guidelines 2015 (version 5.0)
[7]
IEEE Std 11073-10406-2011 Standard for Health informatics - Personal health device
communication - Device specialization - Basic Electrocardiograph (ECG) (1 to 3-lead ECG)
[8]
Heart Rate Service v1.0
[9]
Blood Pressure Service v1.0
[10]
IEEE Std 11073-10407-2008 Standard for Health informatics – Personal health device
communication – Device specialization – Blood Pressure Monitor
[11]
IEEE Std 11073-10417-2011 Standard for Health informatics – Personal health device
communication – Device specialization – Glucose meter
[12]
Glucose Service v1.0
[13]
Bluetooth Core Specification v4.0 or later
[14]
Current Time Service v1.1
[15]
ISO/IEEE Std 11073-10441-2008 Standard for Health Informatics – Personal health device
communication – Device specialization – Cardiovascular fitness and activity monitor
[16]
Specification of Regulatory Certification Data List at ISO/IEEE Std 11073-20601a-2010,
sections 6.3.2.3 (MDS class attributes) and A.11.2 (MDS-related data types).
[17]
Patient Care Device (PCD) Technical Framework at the IHE
site.<http://www.ihe.net/Technical_Frameworks/>
[18]
Weight Scale Service v1.0
[19]
Body Composition Service v1.0
[20]
ISO/IEEE Std 11073-10415-2010 Standard for Health Informatics – Personal health device
communication – Device specialization – Weighing Scale
- 10 [21]
ISO/IEEE Std 11073-10420-2010 Standard for Health Informatics – Personal health device
communication – Device specialization – Body Composition Analyzer
9
Qualification of Bluetooth:
Bluetooth SIG meets the qualifying criteria for normative referencing as per Recommendation ITUT A.5.
10
N/A
Other (for any supplementary information):
- 11 -
Annex 4
A.5 justification information for the reference to GSM/UMTS
1
Clear description of the referenced document:
GSM/UMTS: ETSI TS 123 040 V11.3.0 (2012-10), Digital cellular telecommunications system
(Phase 2+);Universal Mobile Telecommunications System (UMTS); Technical realization of the
Short Message Service (SMS). (3GPP TS 23.040 version 11.3.0 Release 11)
2
Status of approval:
Specification approved at 2012-10.
3
Justification for the specific reference:
The ITU-T H.810 architecture uses Short Message Service (SMS) to provide a means of sending
messages of limited size to and from GSM/UMTS/EPS mobiles.
4
Current information, if any, about IPR issues:
N/A
5
Other useful information describing the "Quality" of the document:
Specification approved at 2012-10 and many qualified devices implementing this version of the
specification exist.
6
The degree of stability or maturity of the document:
See item 5 above.
7
Relationship with other existing or emerging documents:
See item 5 above.
8
Any explicit references within that referenced document should also be listed:
[1] Void
[2] 3GPP TS 22.003: " Circuit Teleservices supported by a Public Land Mobile Network (PLMN)".
[3] 3GPP TS 22.004: "General on supplementary services".
[4] 3GPP TS 22.041: "Operator Determined Barring (ODB)".
[5] 3GPP TS 23.002: "Network architecture".
[6] 3GPP TS 23.008: "Organization of subscriber data".
- 12 [7] 3GPP TS 23.011: "Technical realization of supplementary services".
[8] 3GPP TS 23.015: "Technical realization of Operator Determined Barring (ODB)".
[9] 3GPP TS 23.038: "Alphabets and language-specific information".
[10] 3GPP TS 23.041: "Technical realization of Cell Broadcast Service (CBS)".
[11] Void
[12] 3GPP TS 44.008: "Mobile radio interface layer 3 specification".
[13] 3GPP TS 24.011: "Point-to-Point (PP) Short Message Service (SMS) support on mobile radio
interface".
[14] 3GPP TS 27.005: "Use of Data Terminal Equipment - Data Circuit terminating Equipment
(DTE -DCE) interface for Short Message Service (SMS) and Cell Broadcast Service (CBS)".
[15] 3GPP TS 29.002: "Mobile Application Part (MAP) specification".
[16] 3GPP TS 51.011 Release 4 (version 4.x.x): "Specification of the Subscriber Identity Module Mobile Equipment (SIM- ME) interface".
[17] CCITT Recommendation E.164 (Blue Book): "The international public
telecommunicationnumbering plan".
[18] CCITT Recommendation E.163 (Blue Book): "Numbering plan for the international telephone
service".
[19] CCITT Recommendation Q.771: "Specifications of Signalling System No.7; Functional
description of transaction capabilities".
[20] CCITT Recommendation T.100 (Blue Book): "International information exchange for
interactive videotex".
[21] CCITT Recommendation T.101 (Blue Book): "International interworking for videotex
services".
- 13 [22] CCITT Recommendation X.121 (Blue Book): "International numbering plan for public data
networks".
[23] CCITT Recommendation X.400 (Blue Book): "Message handling services: Message handling
system and service overview".
[24] ISO/IEC10646: "Universal Multiple-Octet Coded Character Set (USC); UCS2, 16 bit coding".
[25] 3GPP TS 22.022: "Personalisation of Mobile Equipment (ME); Mobile functionality
specification".
[26] 3GPP TS 23.042: "Compression Algorithm for Text Messaging Services".
[27] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2".
[28] 3GPP TS 31.115: "Secured packet structure for (U)SIM toolkit application".
[29] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[30] 3GPP TS 31.102: "Characteristics of the USIM application".
[31] 3GPP TS 31.101: "UICC – Terminal interface; Physical and logical characteristics".
[32] 3GPP TS 22.105: "Services and Service Capabilites".
[33] Infrared Data Association. Specifications for Ir Mobile Communications (IrMC). iMelody.
[34] IETF RFC 5322 (October 2008): "Internet Message Format".
[35] Void
[36] "vCard - The Electronic Business Card", version 2.1,The Internet Mail Consortium
(IMC),September 18, 1996, URL:http://www.imc.org/pdi/vcard-21.doc".
[37] "vCalendar - the Electronic Calendaring and Scheduling Format", version 1.0, The Internet
Mail Consortium (IMC), September 18, 1996, URL:http://www.imc.org/pdi/vcal-10.doc
- 14 [38] Scalable Polyphony MIDI Specification, MIDI Manufacturers Association (2002);
http://www.midi.org
[39] Scalable Polyphony MIDI Device 5-to-24 Note Profile for 3GPP, MIDI Manufacturers
Association (2002); http://www.midi.org
[40] The Complete MIDI 1.0 Detailed Specification, Incorporating all Recommended Practices,
MIDI Manufacturers Association, Document version 96.1, 1996; http://www.midi.org
[41] 3GPP TS 23.097: Multiple Subscriber Profile (MSP) (Phase 2) - Stage 2
[42] 3GPP TS 23.204: "Support of SMS over generic 3GPP IP access; Stage 2".
[43] IETF RFC 3261 (June 2002): "SIP: Session Initiation Protocol".
[44] IETF RFC 3428 (December 2002): "Session Initiation Protocol (SIP) Extension for Instant
Messaging".
[45] 3GPP TS 23.272: "Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2".
[46] 3GPP TS 29.272: "Evolved Packet System (EPS); Mobility Management Entity (MME) and
Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol".
[47] 3GPP TS 29.118: "Mobility Management Entity (MME) – Visitor Location Register (VLR)
SGs interface specification".
[48] 3GPP TS 23.682: "Architecture enhancements to facilitate communications with packet data
networks and applications".
[49] 3GPP TS 29.336: "Home Subscriber Server (HSS) diameter interfaces for interworking with
packet data networks and applications".
[50] 3GPP TS 29.338: "Diameter based protocols to support of SMS capable MMEs".
9
Qualification of ETSI:
ETSI is recognized under the provisions of ITU-T Recommendations A.5 and A.6. Qualifying
information is on file at TSB.
- 15 10
N/A
Other (for any supplementary information):
- 16 -
Annex 5
A.5 justification information for the reference to HL7 CDA CD
1
Clear description of the referenced document:
HL7 CDA CD: HL7 Implementation Guide for Clinical Document Architecture, Release 2:
Consent Directives, Release 1
2
Status of approval:
Approved by HL7 as a Draft Standard for Trial Use (DSTU) in 2011-01.
3
Justification for the specific reference:
The ITU-T H.810 architecture uses HL7 Implementation Guide for Clinical Document
Architecture, Release 2 (HL7 CDA CD). The purpose of this document is to describe constraints on
the Clinical Document Architecture Release 2 (CDA R2) header and body elements used to express
Privacy Consent Directive documents.
4
Current information, if any, about IPR issues:
N/A
5
Other useful information describing the "Quality" of the document:
Approved by HL7 as a Draft Standard for Trial Use (DSTU) in 2011-01. The comment period for
use of this draft standard shall end 24 months from the date of publication. Following this 24 month
evaluation period, this draft standard, revised as necessary, will be submitted to a normative ballot
in preparation for approval by ANSI as an American National Standard. Implementations of this
draft standard shall be viable throughout the normative ballot process and for up to six months after
publication of the relevant normative standard.
6
The degree of stability or maturity of the document:
See item 5 above.
7
Relationship with other existing or emerging documents:
See item 5 above.
8
Any explicit references within that referenced document should also be listed:
[1] Composite Privacy Consent Directive Domain Analysis Model (CPCD DAM) – DSTU
February 2010
[2] LOINC: Logical Observation Identifiers Names and Codes, Regenstrief Institute.
http://www.loinc.org
[3] CDA: Clinical Document Architecture Release 2: Clinical Document Architecture (CDA)
Release 2, May 2005. http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm
[4] Health Information Technology Standards Panel (HITSP) Constructs, including the Encounter
Document Using IHE Scanned Document (XDS-SD) Component (C48). http://www.hitsp.org/
- 17 -
9
Qualification of HL7:
Health Level 7 meets the qualifying criteria for normative referencing as per Recommendation ITUT A.5.
10
Other (for any supplementary information):
Same reference as the one using the label [HL7 CDA IG (2011)].
- 18 -
Annex 6
A.5 justification information for the reference to HL7 CDA QFD (2014)
1
Clear description of the referenced document:
HL7 CDA QFD (2014): HL7 Implementation Guide for CDA, Release 2: Questionnaire Form
Definition Document, Release 1
2
Status of approval:
Approved by HL7 as a Draft Standard for Trial Use (DSTU) in 2014-01-31.
3
Justification for the specific reference:
The ITU-T H.810 architecture uses HL7 CDA: Questionnaire Form Definition Document (HL7
CDA QFD). This document describes constraints on the Clinical Document Architecture (CDA)
Release 2 (R2) header and body elements of Questionnaire Form Definition documents. The
purpose of a Questionnaire Form Definition document is to capture the health survey questions or
question sets to be administered to a patient. Questionnaire Form Definition documents enable the
definition of questions for surveying the patient's perceptions on their health and the impact that any
treatments or adjustments to lifestyle have had on their quality of life.
4
Current information, if any, about IPR issues:
N/A
5
Other useful information describing the "Quality" of the document:
Approved by HL7 as a Draft Standard for Trial Use (DSTU) in 2014-01-31. The comment period
for use of this draft standard shall end 24 months from the date of publication. Following this 24
month evaluation period, this draft standard, revised as necessary, will be submitted to a normative
ballot in preparation for approval by ANSI as an American National Standard. Implementations of
this draft standard shall be viable throughout the normative ballot process and for up to six months
after publication of the relevant normative standard.
6
The degree of stability or maturity of the document:
See item 5 above.
7
Relationship with other existing or emerging documents:
See item 5 above.
8
Any explicit references within that referenced document should also be listed:
[1] HL7 Version 3 Interoperability Standards.
<http://www.hl7.org/v3ballot/html/infrastructure/conformance/conformance.htm>
[2] HL7 Clinical Document Architecture (CDA Release 2).
<http://www.hl7.org/implement/standards/cda.cfm>
9
Qualification of HL7:
Health Level 7 meets the qualifying criteria for normative referencing as per Recommendation ITUT A.5.
- 19 10
N/A
Other (for any supplementary information):
- 20 -
Annex 7
A.5 justification information for the reference to HL7 CDA QRD (2014)
1
Clear description of the referenced document:
HL7 CDA QRD (2014): HL7 Implementation Guide for CDA, Release 2: Questionnaire Response
Document, Release 1
2
Status of approval:
Approved by HL7 as a Draft Standard for Trial Use (DSTU) in 2014-01-31.
3
Justification for the specific reference:
The ITU-T H.810 architecture uses HL7 CDA: Questionnaire Response Document (HL7 CDA
QFD). This document describes constraints on the Clinical Document Architecture (CDA) Release
2 (R2) header and body elements of Questionnaire Response documents. The purpose of a
Questionnaire Response document is to capture the health survey answers or answer sets to
questions that have been administered to a patient. Questionnaire Response documents enable the
capture of responses for surveying the patient's perceptions on their health and the impact that any
treatments or adjustments to lifestyle have had on their quality of life.
4
Current information, if any, about IPR issues:
N/A
5
Other useful information describing the "Quality" of the document:
Approved by HL7 as a Draft Standard for Trial Use (DSTU) in 2014-01-31. The comment period
for use of this draft standard shall end 24 months from the date of publication. Following this 24
month evaluation period, this draft standard, revised as necessary, will be submitted to a normative
ballot in preparation for approval by ANSI as an American National Standard. Implementations of
this draft standard shall be viable throughout the normative ballot process and for up to six months
after publication of the relevant normative standard.
6
The degree of stability or maturity of the document:
See item 5 above.
7
Relationship with other existing or emerging documents:
See item 5 above.
8
Any explicit references within that referenced document should also be listed:
[1] HL7 Implementation Guide for CDA Release 2.0: Form Definition Document, Release 1: April
2013 Ballot. <http://www.hl7.org/dstucomments/showdetail.cfm?dstuid=116>
[2] HL7 Version 3 Interoperability Standards.
<http://www.hl7.org/v3ballot/html/infrastructure/conformance/conformance.htm>
- 21 -
[3] HL7 Clinical Document Architecture (CDA Release 2).
<http://www.hl7.org/implement/standards/cda.cfm>
[4] D. Gould et al. "Information Point: Visual Analog Scale (VAS)".
<http://www.cebp.nl/vault_public/filesystem/?ID=1478> (Accessed on 17-March-2013)]
9
Qualification of HL7:
Health Level 7 meets the qualifying criteria for normative referencing as per Recommendation ITUT A.5.
10
N/A
Other (for any supplementary information):
- 22 -
Annex 8
A.5 justification information for the reference to HL7 RLUS (2013)
1
Clear description of the referenced document:
HL7 RLUS (2013): Health Level 7 Service Functional Model Specification - Retrieve, Locate, and
Update Service (RLUS), Release 1
2
Status of approval:
Approved by HL7 as a Draft Standard for Trial Use (DSTU) in 2013-03-22.
3
Justification for the specific reference:
The ITU-T H.810 architecture uses HL7 Retrieve, Locate, and Update Service (RLUS) Service
Functional Model. The RLUS Service Functional Model specify the appropriate capabilities that
must be realized by a service interface to locate, retrieve, and update resources (e.g. documents,
messages) among and within healthcare organizations.
4
Current information, if any, about IPR issues:
N/A
5
Other useful information describing the "Quality" of the document:
Approved by HL7 as a Draft Standard for Trial Use (DSTU) in 2013-03-22. The comment period
for use of this draft standard shall end 24 months from the date of publication. Following this 24
month evaluation period, this draft standard, revised as necessary, will be submitted to a normative
ballot in preparation for approval by ANSI as an American National Standard. Implementations of
this draft standard shall be viable throughout the normative ballot process and for up to six months
after publication of the relevant normative standard.
6
The degree of stability or maturity of the document:
See item 5 above.
7
Relationship with other existing or emerging documents:
See item 5 above.
8
Any explicit references within that referenced document should also be listed:
1 http://hssp.healthinterop.org
2 The term “Interface specification” is intended within the service orientation context, so it's not
restricted to user interface.
3 OMG, Retrieve, Locate, and Update Service (RLUS) Specification,
http://www.omg.org/spec/RLUS/Current
4 http://hssp-rlus-normative.wikispaces.com/
- 23 -
5 http://www.uml.org/
6 http://www.omg.org/spec/BPMN/2.0/
7 http://www.omg.org/spec/SoaML/
9
Qualification of HL7:
Health Level 7 meets the qualifying criteria for normative referencing as per Recommendation ITUT A.5.
10
N/A
Other (for any supplementary information):
- 24 -
Annex 9
A.5 justification information for the reference to IETF RFC 2818 (2000)
1
Clear description of the referenced document:
IETF RFC 2818 (2000): HTTP Over TLS, May 2000
2
Status of approval:
This is an IETF Informational RFC, published in May 2000. Errata exist.
3
Justification for the specific reference:
[INFORMATIONAL RFC] The ITU-T H.810 requires the use of HTTP over TLS for the operation
of medical, health and fitness devices using the WAN interface specifically for its privacy
cryptography for data encryption and its connection reliability and integrity using secure hash
functions. The HTTP over TLS provides use TLS to secure HTTP connections over the Internet.
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=2818
5
Other useful information describing the "Quality" of the document:
SSL, and its successor TLS [RFC2246] were designed to provide channel-oriented security. This
document describes how to use HTTP over TLS.
6
The degree of stability or maturity of the document:
The concepts in this document is sufficiently stable for our use. Updated by RFC 5785. Errata exist.
7
Relationship with other existing or emerging documents:
IETF RFC 1738 "Uniform Resource Locators (URL)", December 1994.
IETF RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1, June 1999
IETF RFC 2660, The Secure HyperText Transfer Protocol, August 1999
IETF RFC 3986 "Uniform Resource Identifier (URI): Generic Syntax", January 2005
8
Any explicit references within that referenced document should also be listed:
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
Public Key Infrastructure: Part I: X.509 Certificate and
CRL Profile", RFC 2459, January 1999.
- 25 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
Protocol, HTTP/1.1", RFC 2616, June 1999.
[RFC2119] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
January 1999.
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
None
Other (for any supplementary information):
- 26 -
Annex 10
A.5 justification information for the reference to IETF RFC 4346 (2006)
1
Clear description of the referenced document:
IETF RFC 4346 (2006): The Transport Layer Security (TLS) Protocol, Version 1.1, April 2006
2
Status of approval:
Proposed Standard. Obsoleted by RFC 5246.
3
Justification for the specific reference:
[OBSOLETED] The ITU-T H.810 requires the use of TLS v1.1 for the operation of medical, health
and fitness devices using the WAN interface specifically for its privacy cryptography for data
encryption and its connection reliability and integrity using secure hash functions. The TLS v1.1
protocol provides sufficient communication privacy over the Internet allowing client/server
applications to communicate in a way that is designed to prevent eavesdropping, tampering, or
message forgery. There is also dependency on the use of this spec across other IHE and HL7 that
also use this version of the TLS protocol.
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=4346
5
Other useful information describing the "Quality" of the document:
This RFC has been in existence since April,2006, obsolescing RFC 2246
6
The degree of stability or maturity of the document:
RFC 4346 is an internet standard. It and its successor are in existence for about 10 years; obsoletes
RFC 2246. Updated by: 4366, 4680, 4681, 5746, 6176. Obsoleted by RFC 5246. Errata exist.
7
Relationship with other existing or emerging documents:
Transport Layer Security (TLS), is a cryptographic protocol which provides secure communications
on the Internet. Other RFCs subsequently extended TLS, including RFC 2712, RFC 2817, RFC
2818, RFC 3546, RFC 4132, RFC 4162 etc.
8
Any explicit references within that referenced document should also be listed:
[AES]
National Institute of Standards and Technology, "Specification for the Advanced
Encryption Standard (AES)" FIPS 197. November 26, 2001.
[3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," IEEE Spectrum, v. 16,
n. 7, July 1979, pp. 40-41.
[DES]
ANSI X3.106, "American National Standard for Information Systems-Data Link
Encryption," American National Standards Institute, 1983.
- 27 [DSS]
NIST FIPS PUB 186-2, "Digital Signature Standard," National Institute of Standards and
Technology, U.S. Department of Commerce, 2000.
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997.
[IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH Series in Information
Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.
[MD5]
Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April 1992.
[PKCS1A] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography
Specifications Version 1.5", RFC 2313, March 1998.
[PKCS1B] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA
Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RC2]
Rivest, R., "A Description of the RC2(r) Encryption Algorithm", RFC 2268, March 1998.
[SCH]
B. Schneier. "Applied Cryptography: Protocols, Algorithms,and Source Code in C, 2ed",
Published by John Wiley & Sons, Inc. 1996.
[SHA]
NIST FIPS PUB 180-2, "Secure Hash Standard," National Institute of Standards and
Technology, U.S. Department of Commerce., August 2001.
[REQ]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC
2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section
in RFCs", BCP 26, RFC 2434, October 1998.
[TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer
Security (TLS)", RFC 3268, June 2002.
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright,
"Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.
- 28 -
[TLSKRB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer
Security (TLS)", RFC 2712, October 1999.
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):
References should always be made to RFC numbers (and not by other designations such as STD,
BCP, etc.). References not to be made to documents referred to as "Internet Drafts" or RFCs
categorized as "Historic". Normative references should not be made to RFCs that are not standards,
for example, "Informational" and "Experimental" RFCs.
- 29 -
Annex 11
A.5 justification information for the reference to IETF RFC 6749 (2012)
1
Clear description of the referenced document:
IETF RFC 6749 (2012): The OAuth 2.0 Authorization Framework
2
Status of approval:
Specification approved at 2012-10.
3
Justification for the specific reference:
The ITU-T H.810 requires the use of OAuth 2.0 Authorization Framework for web services
security. The OAuth 2.0 authorization framework enables a third-party application to obtain limited
access to an HTTP service, either on behalf of a resource owner by orchestrating an approval
interaction between the resource owner and the HTTP service, or by allowing the third-party
application to obtain access on its own behalf.
4
Current information, if any, about IPR issues:
N/A
5
Other useful information describing the "Quality" of the document:
Specification approved at 2012-10 and many devices implementing this version of the specification
exist.
6
The degree of stability or maturity of the document:
See item 5 above.
7
Relationship with other existing or emerging documents:
See item 5 above.
8
Any explicit references within that referenced document should also be listed:
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. BernersLee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and
L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June
1999.
- 30 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629,
November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI):
Generic Syntax", STD 66,RFC 3986, January 2005.
[RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation
(JSON)", RFC 4627, July 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section
in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD
68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version
1.2", RFC 5246, August 2008.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based
Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[USASCII] American National Standards Institute, "Coded Character Set -- 7-bit American
Standard Code for Information Interchange", ANSI X3.4, 1986.
[W3C.REC-html401-19991224] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Recommendation REC-html401-19991224,
December 1999, <http://www.w3.org/TR/1999/REC-html401-19991224>.
[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau,
"Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium
Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml20081126>.
- 31 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
N/A
Other (for any supplementary information):
- 32 -
Annex 12
A.5 justification information for the reference to IETF RFC 6750 (2012)
1
Clear description of the referenced document:
IETF RFC 6750 (2012): The OAuth 2.0 Authorization Framework: Bearer Token Usage
2
Status of approval:
Specification approved at 2012-10.
3
Justification for the specific reference:
The ITU-T H.810 architecture uses bearer tokens in HTTP requests to access OAuth 2.0 protected
resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the
associated resources (without demonstrating possession of a cryptographic key).
4
Current information, if any, about IPR issues:
N/A
5
Other useful information describing the "Quality" of the document:
Specification approved at 2012-10 and many devices implementing this version of the specification
exist.
6
The degree of stability or maturity of the document:
See item 5 above.
7
Relationship with other existing or emerging documents:
See item 5 above.
8
Any explicit references within that referenced document should also be listed:
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. BernersLee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and
L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June
1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
- 33 -
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI):
Generic Syntax", STD 66,RFC 3986, January 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD
68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version
1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet
X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC
5280, May 2008.
[RFC6265]
Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6749]
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012.
[USASCII] American National Standards Institute, "Coded Character Set -- 7-bit American
Standard Code for Information Interchange", ANSI X3.4, 1986.
[W3C.REC-html401-19991224] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Recommendation REC-html401-19991224,
December 1999, <http://www.w3.org/TR/1999/REC-html401-19991224>.
[W3C.REC-webarch-20041215] Jacobs, I. and N. Walsh, "Architecture of the World Wide Web,
Volume One", World Wide Web Consortium Recommendation REC-webarch-20041215,
December 2004, <http://www.w3.org/TR/2004/REC-webarch-20041215>.
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.
- 34 -
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
N/A
Other (for any supplementary information):
- 35 -
Annex 13
A.5 justification information for the reference to OASIS MQTT (2013)
1
Clear description of the referenced document:
OASIS MQTT (2013): OASIS MQTT Version 3.1.1
2
Status of approval:
Specification approved 2013-12-12.
3
Justification for the specific reference:
The ITU-T H.810 architecture uses OASIS MQTT. The MQTT is a Client Server publish/subscribe
messaging transport protocol.
4
Current information, if any, about IPR issues:
N/A
5
Other useful information describing the "Quality" of the document:
Specification approved at 2013-12-12 and some qualified devices implementing this version of the
specification exist.
6
The degree of stability or maturity of the document:
See item 5 above.
7
Relationship with other existing or emerging documents:
See item 5 above.
8
Any explicit references within that referenced document should also be listed:
[RFC793]
Postel, J. Transmission Control Protocol. STD 7, IETF RFC 793, September 1981.
http://www.ietf.org/rfc/rfc793.txt
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. IETF RFC 2119, March
1997.
http://www.ietf.org/rfc/rfc2119.txt
[RFC3629]
- 36 -
F. Yergeau. UTF-8, a transformation format of ISO 10646 IETF RFC 3629, November 2003.
http://www.ietf.org/rfc/rfc3629.txt
[Unicode63]
Unicode 6.3.0 Specification
http://www.unicode.org/versions/Unicode6.3.0/
[RFC5246]
T. Dierks. The Transport Layer Security (TLS) Protocol Version 1.2, August 2008
http://tools.ietf.org/html/rfc5246
[RFC6455]
I Fette. The WebSocket Protocol, IETF RFC 6455, December 2011
http://tools.ietf.org/html/rfc6455
[AES]
Advanced Encryption Standard (AES) (FIPS PUB 197).
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
[DES]
Data Encryption Standard (DES).
http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf
- 37 [PCIDSS]
PCI SSC Data Security Standards
https://www.pcisecuritystandards.org/security_standards/
[SARBANES]
Sarbanes-Oxley Act of 2002. Corporate responsibility.
http://www.gpo.gov/fdsys/pkg/PLAW-107publ204/html/PLAW-107publ204.htm
[USEUSAFEHARB]
U.S.-EU Safe Harbor
http://export.gov/safeharbor/eu/eg_main_018365.asp
1.3 Non normative references
[MQTTV31]
MQTT V3.1 Protocol Specification.
http://public.dhe.ibm.com/software/dw/webservices/wsmqtt/mqttv3r1.htmlhttp://www.ibm.com/developerworks/webservices/library/ws-mqtt/index.html.
[RFC1928]
M Leech. SOCKS Protocol Version 5, March 1996.
http://www.ietf.org/rfc/rfc1928.txt
[RFC4511]
- 38 J. Sermersheim. Lightweight Directory Access Protocol (LDAP): The Protocol, June 2006.
http://tools.ietf.org/html/rfc4511
[RFC6749]
D Hardt The OAuth 2.0 Authorization Framework, October 2012
http://tools.ietf.org/html/rfc6749
[RFC3546]
S. Blake-Wilson Transport Layer Security (TLS) Extensions, June 2003.
http://tools.ietf.org/html/rfc3546
[RFC5077]
J. Salowey Transport Layer Security (TLS) Session Resumption without Server-Side State, January
2008.
http://tools.ietf.org/html/rfc5077
[RFC6960]
S. Santesson X.509 Internet Public Key Infrastructure online Certificate Status Protocol – OCSP,
June 2013.
http://tools.ietf.org/html/rfc6960
[IEEE 802.1AR]
IEEE Standard for Local and metropolitan area networks - Secure Device Identity
http://standards.ieee.org/findstds/standard/802.1AR-2009.html
- 39 [NISTCSF]
Improving Critical Infrastructure Cybersecurity Executive Order 13636
http://www.nist.gov/itl/upload/preliminary-cybersecurity-framework.pdf
[NIST7628]
NISTIR 7628 Guidelines for Smart Grid Cyber Security
http://www.nist.gov/smartgrid/upload/nistir-7628_total.pdf
[FIPS1402]
Federal Information Processing Standards (FIPS-140-2)
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
[PCIDSS]
PCI-DSS Payment Card Industry Data Security Standard
https://www.pcisecuritystandards.org/security_standards/
[NSAB]
NSA Suite B Cryptography
http://www.nsa.gov/ia/programs/suiteb_cryptography/
[RFC6960]
S. Santesson X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
http://tools.ietf.org/html/rfc6960
- 40 -
[RFC5280]
D Cooper Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile
http://tools.ietf.org/html/rfc5280
[ISO29192]
Information technology -- Security techniques -- Lightweight cryptography -- Part 1: General
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=56425
9
Qualification of OASIS:
OASIS is recognized under the provisions of ITU-T Recommendations A.5 and A.4. Qualifying
information is on file at TSB.
10
N/A
Other (for any supplementary information):
- 41 -
Annex 14
A.5 justification information for the reference to TIA-637-C
1
Clear description of the referenced document:
TIA-637-C: TIA-637-C, Short Message Service (SMS) For Wideband Spread Spectrum Systems
2
Status of approval:
Historical specification approved at 2012-11. Transposition of 3GPP2 C.S0015-C v1.0. Superseded
by revision D.
3
Justification for the specific reference:
The ITU-T H.810 architecture uses Short Message Service (SMS) to provide a means of sending
messages of limited size to and from GSM/UMTS/EPS mobiles.
4
Current information, if any, about IPR issues:
N/A
5
Other useful information describing the "Quality" of the document:
Specification approved at 2012-11 and many qualified devices implementing this version of the
specification exist.
6
The degree of stability or maturity of the document:
See item 5 above.
7
Relationship with other existing or emerging documents:
3GPP2 equivalent:
https://global.ihs.com/doc_detail.cfm?&input_doc_number=&input_doc_title=&item_s_key=00231
215&item_key_date=950430&origin=DSSC
8
Any explicit references within that referenced document should also be listed:
1. ISO/IEC 646:1991, Information technology - ISO 7-bit coded character set for information
interchange.
2. ISO/IEC 8348:2002, Information technology - Open Systems Interconnection - Network service
definition.
3. ITU-T Recommendation T.50, International Reference Alphabet (IRA) (Formerly International
Alphabet No. 5 or IA5) - Information technology - 7-bit coded character set for information
interchange.
- 42 4. ITU-T Recommendation X.213, Information technology – Open Systems Interconnection –
Network service definition.
5. ITU-T Recommendation X.25, Interface between Data Terminal Equipment (DTE) and Data
Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to
public data networks by dedicated circuit.
6. ATIS-1000607.2000 (R2009), Integrated Services Digital Network (ISDN) - Layer 3 Signaling
Specification for Circuit Switched Bearer Service for Digital Subscriber Signaling System Number
1 (DSS1).
7. ANSI INCITS 4-1986 (R2007), Information Systems - Coded Character Sets - 7-Bit American
National Standard Code for Information Interchange (7-Bit ASCII).
8. 3GPP2 X.S0004-550-E, Mobile Application Part (MAP) – PARAMETERS SIGNALING
PROTOCOLS, December 2010.
9. 3GPP2 C.S0004-E v3.0, Signaling Link Access Control (LAC) Standard for cdma2000 Spread
Spectrum Systems, May 2011.
10. 3GPP2 C.S0005-E v3.0, Upper Layer (Layer 3) Signaling Standard for cdma2000 Spread
Spectrum Systems, May 2011.
11. 3GPP2 S.R0006, Cellular Features Description.
12. Reserved
13. Reserved
14. TIA/EIA/IS-91-A, Base Station - Mobile Station Compatibility Specification for 800 MHz
Cellular, Auxiliary, and Residential Services (1999), November 1999.
16. IETF RFC 791, Internet Protocol.
17. IETF RFC 822, Standard for the Format of ARPA Internet Text Messages.3GPP2 C.S0015-C
v1.0 1-6
19. 3GPP2 C.S0023-D v2.0, Removable User Identity Module [R-UIM] for 1 Spread Spectrum
Systems, December 2011.
- 43 -
20. 3GPP TS 23.038, Alphabets and Language-Specific Information.
21. 3GPP TS 23.040, Technical Realization of the Short Message Service (SMS).
22. Reserved
23. Reserved
24. WAP-259-WDP-20010614-a, Wireless Datagram Protocol (WDP)
25. Reserved
26. 3GPP2 X.S0024-0 v1.0, IP-Based Location Services, November 2005
27. 3GPP2 C.S0064-0 v2.0, IP-Based Over-the-Air Device Management (IOTA-DM) for cdma2000
Systems, January 2011.
28. 3GPP2 X.S0042-A v1.0, Voice Call Continuity Between IMS and Circuit Switched Systems,
August 2008.
9
Qualification of TIA:
The TIA was recognized under the provisions of ITU-T Recommendation A.5 on 1 November
1999. Qualifying information is on file in TSB.
10
N/A
Other (for any supplementary information):
- 44 -
Annex 15
A.5 justification information for the reference to ZigBee Spec
1
Clear description of the referenced document:
ZigBee Spec: Zigbee Alliance, ZigBee Specification, January 17, 2008
2
Status of approval:
Specification approved at 2008-01-17.
3
Justification for the specific reference:
The ZigBee Specification is needed to allow device inter-connectivity within the ITU-T H.810
personal area network architecture. It enhances the IEEE 802.15.4 standard by adding network and
security layers and an application framework.
4
Current information, if any, about IPR issues:
N/A
5
Other useful information describing the "Quality" of the document:
Specification approved at 2008-01-17 and some qualified devices implementing this version of the
specification exist.
6
The degree of stability or maturity of the document:
See item 5 above.
7
Relationship with other existing or emerging documents:
See item 5 above.
8
Any explicit references within that referenced document should also be listed:
[B1] Institute of Electrical and Electronics Engineers, Inc., IEEE Std. 802.15.4-2003, IEEE
Standard for Information Technology —Telecommunications and Information Exchange
between Systems — Local and Metropolitan Area Networks — Specific Requirements —
Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY)
Specifications for Low Rate Wireless Personal Area Networks (WPANs). New York: IEEE
Press. 2003.
[B2] IEEE 754-1985, IEEE Standard for Binary Floating-Point Arithmetic, IEEE, 1985.
[B3] Document 03285r0: Suggestions for the Improvement of the IEEE 802.15.4 Standard, July
2003.
[B4] Document 02055r4: Network Requirements Definition, August 2003.
- 45 [B5] ISO/IEC 639-1:2002 Codes for the representation of names of languages— Part 1: Alpha-2
code.
[B6] ISO/IEC 646:199 Information technology — ISO 7-bit coded character set for information
interchange.
[B7] ANSI X9.63-2001, Public Key Cryptography for the Financial Services Industry - Key
Agreement and Key Transport Using Elliptic Curve Cryptography, American Bankers Association,
November 20, 2001. Available from http://www.ansi.org.
[B8] FIPS Pub 197, Advanced Encryption Standard (AES), Federal Information Processing
Standards Publication 197, US Department of Commerce/N.I.S.T, Springfield, Virginia, November
26, 2001. Available from http://csrc.nist.gov/.
[B9] FIPS Pub 198, The Keyed-Hash Message Authentication Code (HMAC), Federal Information
Processing Standards Publication 198, US Department of Commerce/N.I.S.T., Springfield, Virginia,
March 6, 2002. Available from http://csrc.nist.gov/.
[B10] ISO/IEC 9798-2, Information Technology - Security Techniques —Entity Authentication
Mechanisms — Part 2: Mechanisms Using Symmetric Encipherment Algorithms, International
Standardization Organization, Geneva, Switzerland, 1994 (first edition). Available from
http://www.iso.org/.
[B11] NIST Pub 800-38A 2001 ED, Recommendation for Block Cipher Modes of Operation —
Methods and Techniques, NIST Special Publication 800-38A, 2001 Edition, US Department of
Commerce/N.I.S.T., December 2001. Available from http://csrc.nist.gov/.
[B12] NIST, Random Number Generation and Testing. Available from http://csrc.nist.gov/rng/.
9
Qualification of ZigBee Alliance:
ZigBee Alliance meets the qualifying criteria for normative referencing as per Recommendation
ITU-T A.5.
10
N/A
Other (for any supplementary information):