From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3240.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc3240.txt (limited to 'doc/rfc/rfc3240.txt') diff --git a/doc/rfc/rfc3240.txt b/doc/rfc/rfc3240.txt new file mode 100644 index 0000000..1911bf3 --- /dev/null +++ b/doc/rfc/rfc3240.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group D. Clunie +Request for Comments: 3240 E. Cordonnier +Category: Informational DICOM Committee + February 2002 + + + Digital Imaging and Communications in Medicine (DICOM) - + Application/dicom MIME Sub-type Registration + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document describes the registration of the MIME sub-type + application/dicom (Digital Imaging and Communications in Medicine). + The baseline encoding is defined by the DICOM Standards Committee in + "Digital Imaging and Communications in Medicine". + +1. DICOM Definition + + Digital Imaging and Communications in Medicine (DICOM) specifies + protocols and formats for the exchange of images, time-based + waveforms, reports, and associated information for medical + applications. + + Individual DICOM objects (such as images) may be encapulsated in + files and exchanged by e-mail using the Media Type defined herein. + In addition, a set of DICOM files may be described by an index file, + DICOMDIR, which may accompany the files that it references. + +2. IANA Registration + + MIME media type name: Application + + MIME subtype name: dicom + + + + + + + + +Clunie, et al. Informational [Page 1] + +RFC 3240 Application/dicom MIME Sub-type Registration February 2002 + + + Required parameters: + + "id" is constructed from a DICOM File ID (see DICOM PS3.11). The + total length is limited to 71 characters. Each component is + limited to 8 characters. The delimiter is a forward slash "/". + There is never a leading delimiter (i.e., this is not a + traditional path from a root directory). + + If a DICOMDIR (which provides an index of files) is included, then + it will refer to other DICOM files in the file set by use of this + File ID. The File ID is not encoded within each DICOM file. If a + DICOMDIR is not present, then the "id" parameter may be absent. + Note that the DICOMDIR will also have a Media Type of + application/dicom and is distinguished from other files by its ID + of "DICOMDIR". + + For example: + "ROOTDIR/SUBDIR1/MRSCAN/A789FD07/19991024/ST00234/S00003/I00023" + + Each component shall be character strings made of characters from + a subset of the G0 repertoire of ISO 8859. This subset consists + of uppercase alphabetic characters, numeric characters and + underscore. The following characters are permissable: + + A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, + W, X, Y, Z (uppercase) + 1, 2, 3, 4, 5, 6, 7, 8, 9, 0 and _ (underscore) + + Optional parameters: + + none + + Encoding considerations: + + The DICOM information is binary, therefore the encoding used shall + support lossless transfer of binary information. Typically, the + Content-Transfer-Encoding would be set to "Base64". + + Multiple DICOM parts should be included as a Multipart/related + entity [2387]. Receiving agents shall also support multiple parts + as a Multipart/mixed entity. When multiple DICOM parts are + included, one of the parts may be a DICOMDIR, in which case, all + the files referred to by the DICOMDIR shall also be present. The + DICOMDIR is not required to be the first Application/dicom part + encoded in the message, in which case the optional "start" + parameter should refer to the content-id of the part containing + the DICOMDIR. + + + + +Clunie, et al. Informational [Page 2] + +RFC 3240 Application/dicom MIME Sub-type Registration February 2002 + + + Multiple DICOM Application/dicom parts may be included with other + types of parts as a Multipart/mixed entity. + + Security considerations: + + Application/dicom parts contain medical information, including + individual demographic information. Accordingly, their exchange + should be restricted to a secure network or within a secure + wrapper that protects a patient's right to confidentiality + according to local and national policy. The specific security + mechanisms are outside the scope of this proposal. Such + mechanisms as Secured MIME (S/MIME) [2633] or similar might be + appropriate. + + Interoperability considerations: + + Because DICOM information is specific to the medical (imaging) + domain, generic e-mail applications may not be able to interpret + the information. + + The Media Type has been designed in order to allow for + + (i) DICOM aware applications to interoperate, + (ii) generic applications to save the files in a form + recognizable as DICOM files, that a DICOM application may + subsequently use. + + Published specification: + + The Digital Imaging and Communications in Medicine (DICOM) + Standard is a standard of the DICOM Standards Committee, published + by the National Electrical Manufacturers Association (NEMA), 1300 + N. 17th Street, Rosslyn, Virginia 22209 USA, + (http://medical.nema.org). + + Applications which use this media: + + Biomedical imaging applications. + + Additional information: + + 1. Magic number(s): "DICM" after 128 byte preamble indicates DICOM + PS 3.10 file + + 2. File extension(s): ".dcm" is recommended for files saved to + disk (other than DICOMDIR) + + + + + +Clunie, et al. Informational [Page 3] + +RFC 3240 Application/dicom MIME Sub-type Registration February 2002 + + + 3. Macintosh file type code: Macintosh File Type "DICM" is + recommended + + 4. Object Identifiers: none + + Person to contact for further information: + + 1. Name: Howard Clark + 2. E-mail: how_clark@nema.org + + Intended usage: + + Common + + Interchange of biomedical images. + + Author/Change controller: + + DICOM Standards Committee + +3. References + + [DICOM] DICOM Standards Committee, "Digital Imaging and + Communications in Medicine", 2001. + + [2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC + 2387, August 1998. + + [2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC + 2633, June 1999. + + + + + + + + + + + + + + + + + + + + + +Clunie, et al. Informational [Page 4] + +RFC 3240 Application/dicom MIME Sub-type Registration February 2002 + + +4. Authors' Addresses + + David Clunie + RadPharm + 943 Heiden Road + Bangor PA 18013 + USA + + Phone: +1-570-897-7123 + Fax: +1-425-930-0171 + EMail: dclunie@dclunie.com + + + Emmanuel Cordonnier + Etiam + 20 rue du Pr J. Pecker + 35000 Rennes + France + + Phone: +33(0)299 14 33 88 + Fax: +33(0)299 14 33 80 + EMail: emmanuel.cordonnier@etiam.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Clunie, et al. Informational [Page 5] + +RFC 3240 Application/dicom MIME Sub-type Registration February 2002 + + +5. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Clunie, et al. Informational [Page 6] + -- cgit v1.2.3