As per Relevance of the word registration, we have this rfc below:
Network Working Group D.
Request for Comments: 3240 E.
Category: Informational DICOM
February 2002
Digital Imaging and Communications in Medicine (DICOM) -
Application/dicom MIME Sub-type
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document describes the registration of the MIME sub-
application/dicom (Digital Imaging and Communications in Medicine).
The baseline encoding is defined by the DICOM Standards Committee
"Digital Imaging and Communications in Medicine".
1. DICOM
Digital Imaging and Communications in Medicine (DICOM)
protocols and formats for the exchange of images, time-
waveforms, reports, and associated information for
applications
Individual DICOM objects (such as images) may be encapulsated
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
MIME media type name:
MIME subtype name:
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).
total length is limited to 71 characters. Each component
limited to 8 characters. The delimiter is a forward slash "/".
There is never a leading delimiter (i.e., this is not
traditional path from a root directory).
If a DICOMDIR (which provides an index of files) is included,
it will refer to other DICOM files in the file set by use of
File ID. The File ID is not encoded within each DICOM file. If
DICOMDIR is not present, then the "id" parameter may be absent
Note that the DICOMDIR will also have a Media Type
application/dicom and is distinguished from other files by its
of "DICOMDIR".
For example
"ROOTDIR/SUBDIR1/MRSCAN/A789FD07/19991024/ST00234/S00003/I00023"
Each component shall be character strings made of characters
a subset of the G0 repertoire of ISO 8859. This subset
of uppercase alphabetic characters, numeric characters
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
Encoding considerations
The DICOM information is binary, therefore the encoding used
support lossless transfer of binary information. Typically,
Content-Transfer-Encoding would be set to "Base64".
Multiple DICOM parts should be included as a Multipart/
entity [2387]. Receiving agents shall also support multiple
as a Multipart/mixed entity. When multiple DICOM parts
included, one of the parts may be a DICOMDIR, in which case,
the files referred to by the DICOMDIR shall also be present.
DICOMDIR is not required to be the first Application/dicom
encoded in the message, in which case the optional "start
parameter should refer to the content-id of the part
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
types of parts as a Multipart/mixed entity
Security considerations
Application/dicom parts contain medical information,
individual demographic information. Accordingly, their
should be restricted to a secure network or within a
wrapper that protects a patient's right to
according to local and national policy. The specific
mechanisms are outside the scope of this proposal.
mechanisms as Secured MIME (S/MIME) [2633] or similar might
appropriate
Interoperability considerations
Because DICOM information is specific to the medical (imaging
domain, generic e-mail applications may not be able to
the information
The Media Type has been designed in order to allow
(i) DICOM aware applications to interoperate
(ii) generic applications to save the files in a
recognizable as DICOM files, that a DICOM application
subsequently use
Published specification
The Digital Imaging and Communications in Medicine (DICOM
Standard is a standard of the DICOM Standards Committee,
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
PS 3.10
2. File extension(s): ".dcm" is recommended for files saved
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"
4. Object Identifiers:
Person to contact for further information
1. Name: Howard
2. E-mail: how_clark@nema.
Intended usage
Interchange of biomedical images
Author/Change controller
DICOM Standards
3.
[DICOM] DICOM Standards Committee, "Digital Imaging
Communications in Medicine", 2001.
[2387] Levinson, E., "The MIME Multipart/Related Content-type",
2387, August 1998.
[2633] Ramsdell, B., "S/MIME Version 3 Message Specification",
2633, June 1999.
Clunie, et al. Informational [Page 4]
RFC 3240 Application/dicom MIME Sub-type Registration February 2002
4. Authors'
David
943 Heiden
Bangor PA 18013
Phone: +1-570-897-7123
Fax: +1-425-930-0171
EMail: dclunie@dclunie.
Emmanuel
20 rue du Pr J.
35000
Phone: +33(0)299 14 33 88
Fax: +33(0)299 14 33 80
EMail: emmanuel.cordonnier@etiam.
Clunie, et al. Informational [Page 5]
RFC 3240 Application/dicom MIME Sub-type Registration February 2002
5. Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Clunie, et al. Informational [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
