doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

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]
+