Subject: MIME-type Review Request: draft-ietf-simple-event-list-05.txt
From: LMM at acm.org (Larry Masinter)
Date: Tue Aug 31 01:16:23 2004

> http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-05.txt

# Optional parameters: charset

#      See RFC 3023 [11] for a discussion of the charset parameter on
#      XML-derived MIME types.  Since this MIME type is used exclusively
#      in SIP, the use of UTF-8 encoding is strongly encouraged.

Not using UTF-8 might be a serious 'interoperability' consideration,
then? 

#  Security considerations: Security considerations specific to uses of
#      this this MIME type are discussed in RFC xxxx [[Note to RFC
#      editor: replace xxxx with the RFC number of this document when
#      published]].  RFC 1874 [10] and RFC 3023 [11] discuss security
#      issues common to all uses of XML.

I don't see a discussion of the security considerations specifically
of this MIME type. What are the risks of someone creating a bogus
rlin? None?

#   Published specification: RFC xxxx [[Note to RFC editor: replace xxxx
#      with the RFC number of this document when published]]

It looks like Section 5.1 has the actual schema, and this kind
of MIME body never appears except as the first part of a multipart/related?
Is that intended? Is there ever a case where there are no other
parts?

#   Interoperability considerations: The use of this MIME body is
#      intended to be generally interoperable.  No unique considerations
#      have been identified.

Is this because of the Intended usage: Limited Use?

Larry
-- 
http://larry.masinter.net

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:46 2006
Subject: MIME-type Review Request: draft-ietf-simple-event-list-05.txt
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-05.txt

# Optional parameters: charset

#      See RFC 3023 [11] for a discussion of the charset parameter on
#      XML-derived MIME types.  Since this MIME type is used exclusively
#      in SIP, the use of UTF-8 encoding is strongly encouraged.

Not using UTF-8 might be a serious 'interoperability' consideration,
then? 

#  Security considerations: Security considerations specific to uses of
#      this this MIME type are discussed in RFC xxxx [[Note to RFC
#      editor: replace xxxx with the RFC number of this document when
#      published]].  RFC 1874 [10] and RFC 3023 [11] discuss security
#      issues common to all uses of XML.

I don't see a discussion of the security considerations specifically
of this MIME type. What are the risks of someone creating a bogus
rlin? None?

#   Published specification: RFC xxxx [[Note to RFC editor: replace xxxx
#      with the RFC number of this document when published]]

It looks like Section 5.1 has the actual schema, and this kind
of MIME body never appears except as the first part of a multipart/related?
Is that intended? Is there ever a case where there are no other
parts?

#   Interoperability considerations: The use of this MIME body is
#      intended to be generally interoperable.  No unique considerations
#      have been identified.

Is this because of the Intended usage: Limited Use?

Larry
-- 
http://larry.masinter.net

From: mankin at psg.com (Allison Mankin)
Date: Mon Aug 30 23:25:50 2004
Subject: Re-Send: MIME-type Review Request: draft-ietf-simple-event-list-05.txt
Message-ID: <[email-masked]>

Trying this again, in case the first one did not go out

------- Forwarded Message

Date:    Mon, 30 Aug 2004 09:19:10 -0700
From:    Allison Mankin <[email-masked]>
To:      [email-masked]
cc:      "Ted Hardie" <[email-masked]>,
	 "Scott Hollenbeck" <[email-masked]>,
	 "Allison Mankin" <[email-masked]>

This is a request for MIME-type review for this document

http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-05.txt

wherein is found the registration of application/rlmi+xml

Please send comments to both the ietf-types list and the cc recipients
listed on this message.

Thank you,

Allison

------- End of Forwarded Message

From: mankin at psg.com (Allison Mankin)
Date: Tue Jan  3 16:22:46 2006
Subject: Re-Send: MIME-type Review Request: draft-ietf-simple-event-list-05.txt
Message-ID: <[email-masked]>

Trying this again, in case the first one did not go out

------- Forwarded Message

Date:    Mon, 30 Aug 2004 09:19:10 -0700
From:    Allison Mankin <[email-masked]>
To:      [email-masked]
cc:      "Ted Hardie" <[email-masked]>,
	 "Scott Hollenbeck" <[email-masked]>,
	 "Allison Mankin" <[email-masked]>

This is a request for MIME-type review for this document

http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-05.txt

wherein is found the registration of application/rlmi+xml

Please send comments to both the ietf-types list and the cc recipients
listed on this message.

Thank you,

Allison

------- End of Forwarded Message

From: mankin at psg.com (Allison Mankin)
Date: Tue Jan  3 16:22:46 2006
Subject: MIME-type Review Request: draft-ietf-simple-event-list-05.txt
Message-ID: <[email-masked]>

This is a request for MIME-type review for this document

http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-05.txt

wherein is found the registration of application/rlmi+xml

Please send comments to both the ietf-types list and the cc recipients
listed on this message.

Thank you,

Allison

From: ned.freed at mrochek.com ([email-masked])
Date: Sun Aug 29 02:40:34 2004
Subject: draft-freed-mime-p4-04 is apparently superseded by..
In-Reply-To: "Your message dated Tue, 24 Aug 2004 09:58:15 -0700" <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I didn't see a LAST CALL or a Protocol Action

> http://www1.ietf.org/mail-archive/web/ietf-announce/current/index.html
 
Which document are you referring to? If you're talking about
draft-freed-mime-p4-03.txt, it was last called on 29-Sep-2003. The announcement
of that last call was posted to the IETF list in the usual way. The document
was finally approved by the IESG on 28-Jan-2004; again with the usual
announcement sent to the IETF list.

However, various concerns relating to the registration of the text/red and
related media types as part of the AVT WG activities caused the IESG to
withdraw the document from the RFC Editor queue so additional changes to the
media type registration procedures section could be made. Additionally, I
suggested, and the IESG agreed, that it would be best to tease the media types
stuff out of the MIME document set at this point since media types are used in
lots of places besides MIME.

Accordingly, I have moved the specification of the media type specification and
registration procedures to another, separate document,
draft-freed-media-type-reg-01.txt. (The additional changes that have been made
in response to AVT needs are listed in the document's appendix.) I presume a
new last call will be needed to advance this specification to BCP at some point
in the future once it has been determined that the various issues have been
dealt with in a satisfactory way.

In the meantime draft-freed-mime-p4-03.txt has gone back into the RFC Editor
queue - an entirely reasonably thing to do IMO given that all the remaining
stuff is unchanged from what was approved back in January.

It is also my understanding that the IESG is currently following and will
continue to follow the revised procedures for registrations in the standards
tree that were specified in  draft-freed-mime-p4-02.txt. The AVT issues and
resulting changes are orthogonal IMO.

				Ned
>From [email-masked]  Mon Aug 30 18:19:10 2004
From: mankin at psg.com (Allison Mankin)
Date: Mon Aug 30 22:55:32 2004
Subject: MIME-type Review Request: draft-ietf-simple-event-list-05.txt
Message-ID: <[email-masked]>

This is a request for MIME-type review for this document

http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-05.txt

wherein is found the registration of application/rlmi+xml

Please send comments to both the ietf-types list and the cc recipients
listed on this message.

Thank you,

Allison

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:46 2006
Subject: draft-freed-mime-p4-04 is apparently superseded by..
In-Reply-To: "Your message dated Tue, 24 Aug 2004 09:58:15 -0700" <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I didn't see a LAST CALL or a Protocol Action

> http://www1.ietf.org/mail-archive/web/ietf-announce/current/index.html
 
Which document are you referring to? If you're talking about
draft-freed-mime-p4-03.txt, it was last called on 29-Sep-2003. The announcement
of that last call was posted to the IETF list in the usual way. The document
was finally approved by the IESG on 28-Jan-2004; again with the usual
announcement sent to the IETF list.

However, various concerns relating to the registration of the text/red and
related media types as part of the AVT WG activities caused the IESG to
withdraw the document from the RFC Editor queue so additional changes to the
media type registration procedures section could be made. Additionally, I
suggested, and the IESG agreed, that it would be best to tease the media types
stuff out of the MIME document set at this point since media types are used in
lots of places besides MIME.

Accordingly, I have moved the specification of the media type specification and
registration procedures to another, separate document,
draft-freed-media-type-reg-01.txt. (The additional changes that have been made
in response to AVT needs are listed in the document's appendix.) I presume a
new last call will be needed to advance this specification to BCP at some point
in the future once it has been determined that the various issues have been
dealt with in a satisfactory way.

In the meantime draft-freed-mime-p4-03.txt has gone back into the RFC Editor
queue - an entirely reasonably thing to do IMO given that all the remaining
stuff is unchanged from what was approved back in January.

It is also my understanding that the IESG is currently following and will
continue to follow the revised procedures for registrations in the standards
tree that were specified in  draft-freed-mime-p4-02.txt. The AVT issues and
resulting changes are orthogonal IMO.

				Ned

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Sat Aug 28 01:04:09 2004
Subject: draft-freed-mime-p4-04 is apparently superseded by.. 
In-Reply-To: Larry Masinter <[email-masked]> 's message of  Tue, 24 Aug 2004 09:58:15 -0700
Message-ID: <[email-masked]>

> I didn't see a LAST CALL or a Protocol Action
> 
> http://www1.ietf.org/mail-archive/web/ietf-announce/current/index.html

According to Ned (I called him), this is indeed the case. He said he'd post an 
explanation here in the near future.

JeffH

> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Jeff Hodges
> > Sent: Saturday, August 21, 2004 12:10 PM
> > To: IETF Types vetting list
> > Subject: draft-freed-mime-p4-04 is apparently superseded by..
> > 
> > draft-freed-mime-p4-05
> > http://www.ietf.org/internet-drafts/draft-freed-mime-p4-05.txt
> > 
> > draft-freed-media-type-reg-01
> > http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt
> > 
> > 
> > MartinD or whomever might want to update their very nice page..
> > 
> >   How to Register a Media Type with IANA (for the IETF tree)
> >   http://www.w3.org/2002/06/registering-mediatype.html
> > 
> > 
> > thanks,
> > 
> > JeffH
> > 
> 

JeffH

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Jan  3 16:22:46 2006
Subject: draft-freed-mime-p4-04 is apparently superseded by.. 
In-Reply-To: Larry Masinter <[email-masked]> 's message of  Tue, 24 Aug 2004 09:58:15 -0700
Message-ID: <[email-masked]>

> I didn't see a LAST CALL or a Protocol Action
> 
> http://www1.ietf.org/mail-archive/web/ietf-announce/current/index.html

According to Ned (I called him), this is indeed the case. He said he'd post an 
explanation here in the near future.

JeffH

> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Jeff Hodges
> > Sent: Saturday, August 21, 2004 12:10 PM
> > To: IETF Types vetting list
> > Subject: draft-freed-mime-p4-04 is apparently superseded by..
> > 
> > draft-freed-mime-p4-05
> > http://www.ietf.org/internet-drafts/draft-freed-mime-p4-05.txt
> > 
> > draft-freed-media-type-reg-01
> > http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt
> > 
> > 
> > MartinD or whomever might want to update their very nice page..
> > 
> >   How to Register a Media Type with IANA (for the IETF tree)
> >   http://www.w3.org/2002/06/registering-mediatype.html
> > 
> > 
> > thanks,
> > 
> > JeffH
> > 
> 

JeffH

From: sla at ucolick.org (Steve Allen)
Date: Thu Sep 16 09:17:07 2004
Subject: MIME Sub-type Registrations for FITS
Message-ID: <[email-masked]>

Greetings.

The FITS Working Group of the International Astronomical Union
has approved the submission of the attached document as
an Internet-Draft in the expectation that it may become
an Informational RFC and result in the registration of the
two MIME media types image/fits and application/fits.

The approval process for this document is visible in the
archives of the IAU FITS Working Group at
http://listmgr.cv.nrao.edu/pipermail/iaufwg/

The call for votes in the IAUFWG is visible at
http://listmgr.cv.nrao.edu/pipermail/iaufwg/2004-July/000200.html

The approval of the document by the IAUFWG is visible at
http://listmgr.cv.nrao.edu/pipermail/iaufwg/2004-August/000212.html

--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
[email-masked]      Voice: +1 831 459 3046     http://www.ucolick.org/~sla
PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93
-------------- next part --------------
Internet-Draft                                                  S. Allen
draft-allen-fitsmime-00.txt                         UCO/Lick Observatory
Category: Informational                                         D. Wells
                                    National Radio Astronomy Observatory
Expires: 2005-02-26                                           2004-08-26

                MIME Sub-type Registrations for FITS

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

   This document may not be modified, and derivative works of it may not
   be created, except to publish it as an RFC and to translate it into
   languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than a "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   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 (2004).  All Rights Reserved.

Abstract

   This document describes the registration of the Multipurpose Internet
   Mail Extensions (MIME) sub-types to be used by the international
   astronomical community for the interchange of FITS files.  The
   encoding is defined by the published FITS standard documents.  The
   FITS format has been in use since 1979, and almost all data from
   astronomical observations are interchanged using FITS.

Allen & Wells                 Informational                     [Page 1]

Internet-Draft              MIME types for FITS               2004-08-26

Table of Contents

   1.  Introduction....................................................2
   2.  Conventions Used in this Document...............................3
   3.  Overview........................................................3
   4.  FITS Definition.................................................3
     4.1  FITS Structure...............................................3
     4.2  History of FITS Features.....................................5
     4.3  Stability of the FITS definition.............................6
     4.4  Portability of FITS files....................................7
     4.5  Application Programming Interfaces to FITS...................8
     4.6  FITS File Conformance Testing................................8
     4.7  Archives That Distribute FITS Files..........................9
   5.  IANA Registration...............................................9
     5.1  application/fits............................................10
     5.2  image/fits..................................................14
   6.  References.....................................................19
     6.1  Normative References........................................19
     6.2  Informative References......................................19
   7.  Security Considerations........................................21
   8.  Contributors...................................................21
   9.  Acknowledgments................................................21
   10.  Authors' Addresses............................................22
   11.  Full Copyright Statement......................................22

1. Introduction

   The FITS file format [FITS] was designed in order to facilitate the
   interchange of astronomical image data between observatories.  FITS
   provides a means of transporting arrays and tables of data and
   keyword/value pairs of metadata.  FITS is defined by standards
   documents that are approved by the International Astronomical Union
   (IAU, http://www.iau.org/) and published in refereed journals.

   Astronomers used the Internet to exchange FITS files before the
   inception of HTTP.  Multiple unofficial media types for FITS files
   [ASU] came into use shortly after the inception of the WWW, and have
   continued in use.  Currently (2004) the international astronomical
   community is engaged in several cooperative efforts (e.g., [NVO],
   [AstroGrid], [AVO]) to produce web services that provide astronomical
   data.  The exchange of FITS files is a fundamental element of the
   prototypes for these web services [SIAP].  The astronomical community
   needs to agree to use one set of media types for FITS files in order
   to promote interoperability of its various services.

   In its simplest form, FITS is used as a means of transporting
   astronomical image data in a raster form along with coordinate
   information and other standard and locally defined metadata.  In such
   applications FITS is much like the well-known TIFF format [TIFF] with
   the addition of the GeoTIFF tags [GeoTIFF].  However, FITS is capable
   of describing a much broader range of data than 2-dimensional
   rasters.  A consensus has developed in the FITS community that two
   media types are needed, one for images and one for all other cases.

Allen & Wells                 Informational                     [Page 2]

Internet-Draft              MIME types for FITS               2004-08-26

2. Conventions Used in this Document

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [Require].

3. Overview

   This document describes the registration of the MIME media sub-types
   "application/fits" and "image/fits".

   In 1988 the International Astronomical Union formed the FITS Working
   Group (IAUFWG) to oversee matters pertaining to the evolution of the
   FITS data format.  The IAUFWG has approved the submission of this
   document and the registration of these two MIME types.

4. FITS Definition

   FITS is defined by a document approved by the International
   Astronomical Union (IAU) and published in the journal Astronomy &
   Astrophysics [NOST].  Conventions for additional keywords used in
   FITS files are proposed by interested parties and negotiated and
   reviewed by ad hoc committees of the FITS community.  If such usage
   of additional keywords is approved by national committees and the
   IAUFWG then they become new reserved keywords in the FITS standard
   and are published in an ongoing series of papers (e.g., [WCS1,
   WCS2]).

   Copies of the standard documents can also be found via:

   http://fits.gsfc.nasa.gov/

   http://archive.stsci.edu/fits/

   http://www.cv.nrao.edu/fits/

   http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html

   While a brief structure and feature description is provided in this
   section as background information, the reader is directed to the FITS
   standards documents to obtain complete feature and technical details.

4.1 FITS Structure

   A FITS file consists of a sequence of one or more header and data
   units (HDUs) optionally followed by special records.  The structure
   of a FITS file is based on blocks with a length of 2880 8-bit bytes
   (23040 bits).  This size was chosen to be evenly divisible by the
   byte and word lengths of all known computer systems.  All FITS files
   have lengths that are integral multiples of this block size.

Allen & Wells                 Informational                     [Page 3]

Internet-Draft              MIME types for FITS               2004-08-26

   Each FITS header consists of a sequence of one or more 2880-byte
   blocks that hold 36 80-character records (36*80=2880).  The records
   consist of ASCII keyword/value pairs plus optional comments.  The
   character set is the 7-bit printing ASCII codes, including the ASCII
   space.  In particular, the control codes CR, LF, FF, TAB and NUL are
   not used in FITS headers.  The keywords are up to 8 characters in
   length.  Some keywords are mandatory, and their meaning is rigidly
   prescribed.  Among these are keywords that describe the structure and
   size of the subsequent data array.  The standard reserves other
   keywords for the purpose of conveying specifically defined items of
   metadata.  Keywords that are neither mandatory nor reserved may be
   inserted with semantics that are defined by local conventions.  (Some
   local conventions have later been adopted into standardized
   practice.)  The end of the header is signified by a block containing
   the keyword "END".  A simple example of a FITS header for a digital
   image, using only keywords that were specified in the initial FITS
   Agreement of March 1979 [FITS], is:

            1         2         3         4         5         6
   1234567890123456789012345678901234567890123456789012345678901234567..

   SIMPLE  =                    T / file does conform to FITS standard
   BITPIX  =                   16 / 16-bit twos-complement pixel values
   NAXIS   =                    2 / 2-dimensional image
   NAXIS1  =                  512 / first axis length
   NAXIS2  =                  512 / second axis length
   COMMENT  -----------------------------------------------------
   COMMENT   FITS (Flexible Image Transport System) format is defined
   COMMENT   in 'Astronomy and Astrophysics', volume 376, page 359;
   COMMENT   bibcode: 2001A&A...376..359H
   COMMENT  -----------------------------------------------------
   ORIGIN  = 'Lick Observatory   ' /
   DATE    = '2003-11-22T05:23:45' / when this file was written
   END
   (these 13 records are followed by 23 80-character records of ASCII
   spaces,  to pad the header block to the 2880-byte FITS block size)

   The first keyword/value pair, SIMPLE=T, is the signature of FITS; all
   FITS files begin with these characters.  BITPIX is the second keyword
   of all FITS files; legal values for it are 8, 16, 32, -32 and -64.
   NAXIS is the third keyword of all FITS files; legal values for it are
   0 to 999.  NAXIS=0 is legal, and implies that there is no image data
   matrix associated with the header (and the NAXISi keywords must not
   be present); this value is common for files which will be given the
   media type 'application/fits' as discussed in section 5.1 of this
   document.  NAXIS=2 is the value most often used for files which will
   be given the media type 'image/fits', as discussed in section 5.2 of
   this document (NAXIS=3 FITS images are also common).  The COMMENT
   records will be ignored by FITS reading software, but are used here
   to specify the precise journal citation for the FITS standard, an
   item of information which is important for archiving on timescales of

Allen & Wells                 Informational                     [Page 4]

Internet-Draft              MIME types for FITS               2004-08-26

   decades.  The ORIGIN keyword is commonly used in FITS files to encode
   the name of the institution where the file was produced.  The DATE
   keyword is used to convey the time-stamp for the file (keyword
   DATE-OBS is used to convey observation start times).  FITS headers
   commonly contain a vast variety of additional keywords used to encode
   metadata.  In particular, a digital image header will often include
   keywords to specify the precise celestial coordinates of the pixels
   of the 2-D matrix, using conventions which became part of the FITS
   standard in 2002 (see [WCS2]).  Finally, the above example
   demonstrates how, in addition to the COMMENT records, 60% of the
   bytes in keyword=value records in FITS headers are reserved for
   comments.  Although the simple header example above is contained in
   only one FITS block, multi-block FITS headers are commonly
   interchanged.

   Following each header is a data unit that consists of a sequence of
   zero or more 2880-byte blocks.  In accordance with the description in
   the keywords of their header, these blocks contain an N-dimensional
   data array, optionally followed by other small groups of array data.
   In most cases the data array represents either an N-dimensional array
   of image pixel values or a 2-dimensional array of tabular data.

   Following the HDUs a FITS file may contain zero or more 2880-byte
   blocks of special records.  The standard does not specify anything
   about their content.  (This convention for special records is not
   known to have been used for any purpose other than prototyping new
   elements of the standard, such as random groups and BINTABLE.)

   The initial HDU in a FITS file is known as the primary HDU (PHDU);
   any subsequent HDU is known as an extension HDU (XHDU).  The keyword
   content of the PHDU is distinct (a PHDU requires a slight alteration
   before it can become an XHDU, and most types of XHDU cannot become a
   PHDU).  A PHDU may have a data array consisting of zero elements, and
   this will often be the case for FITS files intended to communicate
   tables and multiple images.  An XHDU may be one of several standard
   types, or it may be another conforming type.  Standard types of XHDU
   include "IMAGE" (containing an N-dimensional data array similar in
   most respects to the PHDU), "TABLE" (containing a 2-dimensional table
   of ASCII character data), and "BINTABLE" (containing a 2-dimensional
   table of binary data whose elements may themselves be
   multi-dimensional arrays).

4.2 History of FITS Features

   In 1981 the original definition of FITS described a single HDU
   containing one multi-dimensional image array [FITS], as illustrated
   by the sample header shown in section 4.1.  Subsequent agreements
   have used the original framework of HDUs and keyword/value pairs to
   extend FITS while preserving the validity of all existing files.
   FITS now has standard means of describing multiple arrays of image
   data and/or multiple tables of numeric and character information.

Allen & Wells                 Informational                     [Page 5]

Internet-Draft              MIME types for FITS               2004-08-26

   Brief highlights of the history of FITS

    - 1979: Initial FITS Agreement and first interchange of files

    - 1980: Random groups convention developed

    - 1981: Published original (single HDU) definition [FITS]

    - 1981: Published random groups definition [GROUPS]

    - 1982: Formally endorsed by the IAU

    - 1988: Defined rules for multiple HDUs [XTENSION]

    - 1988: FITS Working Group established by IAU [IAUFWG]

    - 1988: Extended to include ASCII tables [TABLE]

    - 1990: Extended to include IEEE floating-point data

    - 1994: Extended to multiple image arrays [IMAGE]

    - 1995: Extended to binary tables [BINTABLE]

    - 1997: Adopted a Y2K-compliant date format

    - 2001: Reiterated existing standard in one paper [NOST]

    - 2002: Approved conventions for world coordinates [WCS1, WCS2]

4.3 Stability of the FITS definition

   After the adoption of FITS by the IAU in 1982, some in the emerging
   community of FITS users realized that there would be tension between
   the need for archival stability and the need for evolution.  In order
   to satisfy both of these requirements they set up a controlled
   parliamentary process.  At the time of the Generalized Extensions
   Agreement [XTENSION], the meta-agreement that controls the evolution
   of FITS, the FITS community adopted the guiding principle "Once FITS,
   always FITS".  Under this rule no change may be made to FITS which
   invalidates existing files.  Changes to the FITS standard occur only
   after action by the IAU FITS Working Group (FWG).  The FWG acts only
   after approval by regional working groups that coordinate FITS
   activity in various parts of the world.

   FITS has been adopted as the archival format for image data and
   interferometric data obtained by many ground-based observatories and
   for all data from many spacecraft.  Many astrophysical archives store
   their data in FITS format, and most astronomical catalog data has
   been transcribed into FITS files.  The many terabytes of data in
   these archives contribute to the stability of the FITS standard.

Allen & Wells                 Informational                     [Page 6]

Internet-Draft              MIME types for FITS               2004-08-26

4.4 Portability of FITS files

   Eric Greisen, one of the authors of the original document [FITS],
   relates that in 1979

      The first FITS files were written by a PL/I program on an IBM 360
      under OS/MFT (32-bit, twos-complement numbers and 8-bit EBCDIC
      characters) and were read by a Fortran program executing on a CDC
      6400 under SCOPE (60-bit, ones-complement numbers and 6-bit
      "Display Code" characters).[Remark]

   Subsequent evolution of computing hardware and FITS over 25 years
   have not degraded this ability to transfer the data content.

   The structure of FITS files is extremely general, and this
   necessarily complements the nature of astronomical data.  FITS is
   used to store observations of the entire electromagnetic spectrum
   from radio to gamma rays, from ground-based observatories and from
   spacecraft.  FITS is also used to communicate physical properties
   other than radiation intensity; these may be inferred from
   observations or calculated by theoretical models.  The pedigree of
   data in a FITS file typically varies among disciplines; FITS may be
   used to store raw and uncalibrated data, or completely reduced and
   calibrated data, or both.  Nevertheless, the FITS standard provides
   that the syntactic content of the data and metadata are unambiguously
   available to posterity.

   Observatories have developed numerous local conventions for the
   storage and transfer of data peculiar to their instrumentation and
   purview.  Application software for handling FITS files from different
   regions of the electromagnetic spectrum has been largely disjoint.
   For a FITS file which consists of multiple HDUs there are no widely
   established conventions governing the meaning of, interrelations
   between, and suggested use of the data sets.  Recognition of any
   local conventions used for FITS data has often been based on
   heuristics of the additional (non-standard) keyword/value pairs.
   Fully understanding the semantic content of a FITS file usually
   requires an external data dictionary.

Allen & Wells                 Informational                     [Page 7]

Internet-Draft              MIME types for FITS               2004-08-26

4.5 Application Programming Interfaces to FITS

   Although the definition of FITS is expressed in terms of the bit
   content of the files, there are widely-supported application
   programming interfaces (APIs) which simplify the task of manipulating
   FITS files.  Interfaces exist for many languages and operating
   systems.  A partial list of APIs follows:

   CFITSIO      http://heasarc.gsfc.nasa.gov/fitsio/
   fitsTcl      http://heasarc.gsfc.nasa.gov/ftools/fv/fitsTcl_home.html
   WCSLIB       http://www.atnf.csiro.au/people/mcalabre/WCS/
   PyFITS       http://www.stsci.edu/resources/software_hardware/pyfits
   WCSTools     http://tdc-www.harvard.edu/software/wcstools/
   FUNTOOLS     http://hea-www.harvard.edu/RD/funtools/
   IDLASTRO     http://idlastro.gsfc.nasa.gov/
   fitsy        http://cfa-www.harvard.edu/~john/fitsy/
   IUEDAC       http://archive.stsci.edu/iue/iuedacfits.html
   Mathematica  http://documents.wolfram.com/v5/Built-inFunctions/
                       GraphicsAndSound/ImportAndExport/
                       AdditionalInformation/Import.html
   MatLab       http://www.mathworks.com/access/helpdesk/help/techdoc/
                       ref/fitsread.shtml?cmdname=fitsread

   Current lists of more APIs can be found at
   http://fits.gsfc.nasa.gov/fits_libraries.html

   List of applications that use FITS are found in the IANA
   registrations of the media types.

4.6 FITS File Conformance Testing

   FITS files can be tested for conformance to the Definition of FITS
   rules [NOST, WCS1, WCS2] with an application named 'fitsverify',
   which is available at

   http://heasarc.gsfc.nasa.gov/docs/software/ftools/fitsverify/

   in the form of executable binary files for Solaris, Linux, and
   Windows platforms, as well as in source code.  Although 'fitsverify'
   has not been endorsed by the IAUFWG, users should be aware that the
   designer of the program was the Secretary of the Technical Panel
   which produced the published FITS standard [NOST].

Allen & Wells                 Informational                     [Page 8]

Internet-Draft              MIME types for FITS               2004-08-26

4.7 Archives That Distribute FITS Files

   As noted in Section 4.3 of this RFC, massive (multi-terabyte) data
   archives which contain and/or distribute FITS files contribute to the
   stability of the FITS standard.  There are numerous publicly
   available archives of FITS files derived from both space and
   ground-based observations that span the entire range of the
   electromagnetic spectrum from radio to gamma-ray wavelengths.
   Examples of such archives, in no particular order, include:

   Telescope(s)   URLs for archive access
   ------------   ------------------------------------------------------
   KPNO,CTIO,..   http://iraf.noao.edu/projects/stb/archive.html
   VLT,HST,..     http://archive.eso.org/
   Subaru         http://moka.nao.ac.jp/
   SDSS           http://www.sdss.org/dr1/
   CFHT           http://cadcwww.dao.nrc.ca/cfht/cfht.html
   VLA,VLBA,GBT   http://e2e.aoc.nrao.edu/archive/archive_describe.html
   HST,MAST       http://archive.stsci.edu/
   HEASARC        http://heasarc.gsfc.nasa.gov/w3browse/
   Chandra        http://cxc.harvard.edu/cda/
   LaPalma        http://archive.ast.cam.ac.uk/ingarch/
   BIMA           http://bimaarch.ncsa.uiuc.edu/
   Keck-DEIMOS    http://archive.deep.ucolick.org/
   ComptonGRO     http://cossc.gsfc.nasa.gov/archive/index.html
   Spitzer,..     http://www.ipac.caltech.edu/
   AAT            http://www.aao.gov.au/archive/
   HIPASS         http://www.atnf.csiro.au/research/multibeam/
                          multibeam.html
   JCMT           http://salish.dao.nrc.ca:8080/jcmt/intro.html
   COBE,WMAP      http://lambda.gsfc.nasa.gov/
   EVN            http://www.jive.nl/archive/scripts/listarch.php
   Gemini         http://gemini.ast.cam.ac.uk/sciops/data/dataIndex.html
   XMM-Newton     http://xmm.vilspa.esa.es/external/xmm_data_acc/xsa/

5. IANA Registration

   The general nature of the full FITS standard requires the use of the
   media type "application/fits".  Nevertheless, the principal intent
   for a great many FITS files is to convey a single data array in the
   PHDU, and such arrays are very often 2-dimensional images.  Several
   common image viewing applications already display single-HDU FITS
   files, and the prototypes for virtual observatory projects specify
   that data provided by web services be conveyed by the data array in
   the PHDU.  These uses justify the registration of a second media
   type, namely "image/fits", for files which use the subset of the
   standard described by the original FITS standard paper [FITS].

Allen & Wells                 Informational                     [Page 9]

Internet-Draft              MIME types for FITS               2004-08-26

   We note that the media type "image/gif" [MIME2] admits raster images
   which are three dimensional, because animated GIF images contain two
   spatial dimensions and one temporal dimension.  We note that the
   media types "image/vnd.dwg" and "image/vnd.dxf" admit data which
   include three dimensional vectors and curves as well as objects
   created using constructive solid geometry.  Following these
   precedents for the "image" media type, we specify that "image/fits"
   MAY be used to describe FITS PHDUs that have other than two
   dimensions.  We expect that the majority of files described as
   "image/fits" will have two-dimensional (NAXIS=2) PHDUs.

5.1 application/fits

   To: [email-masked]
   Subject: Registration of Standard MIME Media type application/fits

   MIME media type name: application

   MIME subtype name: fits

   Required parameters: none

   Optional parameters: none

   Encoding considerations: binary

   FITS files can be quite large.  When transferred via HTTP it may be
   efficient for the transaction to make use of content-coding or
   transfer-coding values such as "gzip", "compress", or "deflate".

   Security considerations:

   FITS provides a means of transporting arrays and tables of data and
   keyword/value pairs of metadata.  The standard FITS keywords are
   either mandatory or reserved.  Mandatory keywords provide information
   necessary for correct interpretation of the data; reserved keywords
   merely provide standard bits of metadata.  As such, the current
   standard FITS keywords do not pose security risks.

   A FITS file author may insert additional keywords with semantics that
   are not described by the standard.  Parties exchanging FITS files may
   employ locally defined conventions that use various keywords and
   their values to induce actions on the part of the recipient.  There
   are existing local conventions where such keywords are used to
   request the reading of other files and/or URIs.  There are other
   local conventions where such keywords are used to modify the state of
   a telescope and/or instrument.  The security implications of local
   conventions such as these SHOULD be analyzed by the parties employing
   them.

Allen & Wells                 Informational                    [Page 10]

Internet-Draft              MIME types for FITS               2004-08-26

   Interoperability considerations:

   FITS files have been successfully transported between wildly
   different computers since 1979.  The difficulty most likely to be
   encountered by a FITS application is inability to acquire the
   computational resources required by a very large FITS file.

   Published specification:

   The specification for this content type is published as a series of
   papers in refereed astronomical journals:

   Hanisch, R., et al., "Definition of the Flexible Image Transport
   System (FITS)", Astronomy & Astrophysics, 376, p. 359, 2001.

   Greisen, E. and M. Calabretta, "Representations of world coordinates
   in FITS", Astronomy & Astrophysics, 395, p. 1061, 2002.

   Calabretta, M. and E. Greisen, "Representations of celestial
   coordinates in FITS", Astronomy & Astrophysics, 395, p. 1077, 2002.

   Copies of these specifications can also be found via:

   http://fits.gsfc.nasa.gov/
   http://archive.stsci.edu/fits/
   http://www.cv.nrao.edu/fits/
   http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html

   Applications that use this media type:

   There are many astronomical image viewing and data reduction
   applications including, but not limited to, the following list:

   IRAF     http://iraf.noao.edu/
   AIPS     http://www.aoc.nrao.edu/aips/
   AIPS++   http://aips2.nrao.edu/
   MIDAS    http://www.eso.org/projects/esomidas/
   ds9      http://hea-www.harvard.edu/RD/ds9/
   fv       http://heasarc.gsfc.nasa.gov/ftools/fv/
   Aladin   http://aladin.u-strasbg.fr/
   Starlink http://star-www.rl.ac.uk/
   Miriad   http://bima.astro.umd.edu/miriad/
   STSDAS   http://www.stsci.edu/resources/software_hardware/stsdas
   PROS     http://hea-www.harvard.edu/PROS/pros.html
   CIAO     http://asc.harvard.edu/ciao/
   XANADU   http://heasarc.gsfc.nasa.gov/docs/xanadu/xanadu.html
   HESSI    http://hesperia.gsfc.nasa.gov/ssw/hessi/doc/
   FITSview http://www.nrao.edu/software/fitsview/
   XMM-SAS  http://xmm.vilspa.esa.es/external/xmm_sw_cal/sas_frame.shtml

   At the present time many of these applications are not designed to
   support use as viewers of 'application/fits' files in association
   with web browsers.

Allen & Wells                 Informational                    [Page 11]

Internet-Draft              MIME types for FITS               2004-08-26

   Additional information:

   A FITS file described with the media type "application/fits" SHOULD
   conform to the published standards for FITS files as determined by
   convention and agreement within the international FITS community.  No
   other constraints are placed on the content of a file described as
   "application/fits".

   A FITS file described with the media type "application/fits" may have
   an arbitrary number of conforming extension header and data units
   (XHDUs) that follow its mandatory primary header and data unit
   (PHDU).  The XHDUs may be one of the standard types ("IMAGE",
   "TABLE", and "BINTABLE") or any other type that satisfies the
   'Requirements for Conforming Extensions' (section 4.4.1 of [NOST]).
   The PHDU or any "IMAGE" XHDU may contain zero to 999 dimensions with
   zero or more pixels along each dimension.

   The PHDU may use the random groups convention, in which the dimension
   of the first axis is zero and the keywords GROUPS, PCOUNT and GCOUNT
   appear in the header.  NAXIS1=0 and GROUPS=T is the signature of
   random groups; see section 7 of the Definition of FITS paper [NOST].

   Recommendations for application writers:

   An application intended to handle "application/fits" SHOULD be able
   to provide a user with a manifest of all of the HDUs that are present
   in the file and with all of the keyword/value pairs from each of the
   HDUs.

   An application intended to handle "application/fits" SHOULD be
   prepared to encounter XHDUs that contain either ASCII or binary
   tables, and to provide a user with access to their elements.

   An application which can modify FITS files or retrieve FITS files
   from an external service SHOULD be capable of writing such files to a
   local storage medium.

   Complete interpretation of the meaning and intended use of the data
   in each of the HDUs typically requires the use of heuristics that
   attempt to ascertain which local conventions were used by the author
   of the FITS file.

   As examples, files with media type "application/fits" might contain
   any of the following contents:

     - An empty PHDU (containing zero data elements) followed by a table
       HDU that contains a catalog of celestial objects.

     - An empty PHDU followed by a table HDU that encodes a series of
       time-tagged photon events from an exposure using an X-ray
       detector.

Allen & Wells                 Informational                    [Page 12]

Internet-Draft              MIME types for FITS               2004-08-26

     - An empty PHDU followed by a series of IMAGE HDUs containing data
       from an exposure taken by a mosaic of CCD detectors.

     - An empty PHDU followed by a series of table HDUs that contain a
       snapshot of the state of a relational database.

     - A PHDU containing a single image along with keyword/value pairs
       of metadata.

     - A PHDU with NAXIS1=0 and GROUPS=T followed by random groups data
       records of complex fringe visibilities

   Magic number(s): "SIMPLE  =                    T"

   Jeff Uphoff of the National Radio Astronomy Observatory (NRAO) has
   contributed database entries for the magic number file which is used
   by the Unix "file" command.  Magic number files with these entries
   are distributed with a variety of Unix-like operating systems.  In
   addition to recognizing a FITS file using the string given above, the
   Uphoff entries also recognize the data type of the pixels in the
   PHDU.

   File extension(s): fits

   This file extension SHOULD NOT be interpreted as a prescription.

   The FITS standard originated in the era when files were stored and
   exchanged via magnetic tape; it does not prescribe any nomenclature
   for files on disk.  Various sites within the FITS community have
   long-established practices where files are presumed to be FITS by
   context.  File extensions used at such sites commonly indicate
   content of the file instead of the data format.

   In the absence of other information it is reasonably safe to presume
   that a file name ending in ".fits" is intended to be a FITS file.
   Nevertheless, there are other commonly used extensions; e.g., ".fit",
   ".fts", and many others not suitable for listing in a media type
   registration.

   Intended usage: Common

   Persons to contact for further information:

   "Steve Allen"     <[email-masked]>
   "Don Wells"       <[email-masked]>

   Author/Change controller:

   "Steve Allen" <[email-masked]>

   The IAU FITS Working Group may authorize changes to this document.

Allen & Wells                 Informational                    [Page 13]

Internet-Draft              MIME types for FITS               2004-08-26

5.2 image/fits

   To: [email-masked]
   Subject: Registration of Standard MIME Media type image/fits

   MIME media type name: image

   MIME subtype name: fits

   Required parameters: none

   Optional parameters: none

   Encoding considerations: binary

   FITS files can be quite large.  When transferred via HTTP it may be
   efficient for the transaction to make use of content-coding or
   transfer-coding values such as "gzip", "compress", or "deflate".

   Security considerations:

   FITS provides a means of transporting arrays and tables of data and
   keyword/value pairs of metadata.  The standard FITS keywords are
   either mandatory or reserved.  Mandatory keywords provide information
   necessary for correct interpretation of the data; reserved keywords
   merely provide standard bits of metadata.  As such, the current
   standard FITS keywords do not pose security risks.

   A FITS file author may insert additional keywords with semantics that
   are not described by the standard.  Parties exchanging FITS files may
   employ locally defined conventions that use various keywords and
   their values to induce actions on the part of the recipient.  There
   are existing local conventions where such keywords are used to
   request the reading of other files and/or URIs.  There are other
   local conventions where such keywords are used to modify the state of
   a telescope and/or instrument.  The security implications of local
   conventions such as these SHOULD be analyzed by the parties employing
   them.

   Interoperability considerations:

   FITS files have been successfully transported between wildly
   different computers since 1979.  The difficulty most likely to be
   encountered by a FITS application is inability to acquire the
   computational resources required by a very large FITS file.

Allen & Wells                 Informational                    [Page 14]

Internet-Draft              MIME types for FITS               2004-08-26

   Published specification:

   The specification for this content type is published as a series of
   papers in refereed astronomical journals:

   Hanisch, R., et al., "Definition of the Flexible Image Transport
   System (FITS)", Astronomy & Astrophysics, 376, p. 359, 2001.

   Greisen, E.  and M.  Calabretta, "Representations of world
   coordinates in FITS", Astronomy & Astrophysics, 395, p.  1061, 2002.

   Calabretta, M. and E. Greisen, "Representations of celestial
   coordinates in FITS", Astronomy & Astrophysics, 395, p. 1077, 2002.

   Copies of these specifications can also be found via:

   http://fits.gsfc.nasa.gov/
   http://archive.stsci.edu/fits/
   http://www.cv.nrao.edu/fits/
   http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html

   Applications that use this media type:

   There are many astronomical image viewing and data reduction
   applications including, but not limited to, the following list:

   IRAF     http://iraf.noao.edu/
   AIPS     http://www.aoc.nrao.edu/aips/
   AIPS++   http://aips2.nrao.edu/
   MIDAS    http://www.eso.org/projects/esomidas/
   ds9      http://hea-www.harvard.edu/RD/ds9/
   fv       http://heasarc.gsfc.nasa.gov/ftools/fv/
   Aladin   http://aladin.u-strasbg.fr/
   Starlink http://star-www.rl.ac.uk/
   Miriad   http://bima.astro.umd.edu/miriad/
   STSDAS   http://www.stsci.edu/resources/software_hardware/stsdas
   PROS     http://hea-www.harvard.edu/PROS/pros.html
   CIAO     http://asc.harvard.edu/ciao/
   XANADU   http://heasarc.gsfc.nasa.gov/docs/xanadu/xanadu.html
   HESSI    http://hesperia.gsfc.nasa.gov/ssw/hessi/doc/
   FITSview http://www.nrao.edu/software/fitsview/
   XMM-SAS  http://xmm.vilspa.esa.es/external/xmm_sw_cal/sas_frame.shtml

   Non-astronomical FITS image display applications include:

   netpbm          http://netpbm.sourceforge.net/
   gimp            http://www.gimp.org/
   IDL             http://www.rsinc.com/
   ImageMagick     http://www.imagemagick.com/
   Mathematica     http://www.wolfram.com/
   MatLab          http://www.mathworks.com/
   xv              http://www.trilon.com/xv/xv.html

Allen & Wells                 Informational                    [Page 15]

Internet-Draft              MIME types for FITS               2004-08-26

   There are also two FITS plug-ins for Adobe Photoshop
   (http://www.adobe.com/products/photoshop/), available at
   http://astroshed.com/fitsplug/fitsplug.htm and
   http://www.spacetelescope.org/projects/fits_liberator/

   At the present time many of the applications listed above are not
   designed to support use as viewers of 'image/fits' files in
   association with web browsers.

   Additional information:

   A FITS file described with the media type "image/fits" SHOULD have a
   PHDU with positive integer values for the NAXIS and NAXISn keywords,
   and hence SHOULD contain at least one pixel.  Files with 4 or more
   non-degenerate axes (NAXISn>1) SHOULD be described as
   'application/fits', not as 'image/fits'.  (In rare cases it may be
   appropriate to describe a NULL image -- a dataless container for FITS
   keywords, with NAXIS=0 or NAXISn=0 -- or an image with 4+
   non-degenerate axes as 'image/fits' but this usage is discouraged
   because such files may confuse simple image viewer applications.)

   FITS files declared as 'image/fits' MAY also have one or more
   conforming XHDUs following their PHDUs.  These extension HDUs MAY
   contain standard, non-linear, world coordinate system (WCS)
   information in the form of tables or images.  The extension HDUs MAY
   also contain other, non-standard metadata pertaining to the image in
   the PHDU in the forms of keywords and tables.

   A FITS file described with the media type "image/fits" SHOULD be
   principally intended to communicate the single data array in the
   PHDU.  This means that "image/fits" SHOULD NOT be applied to FITS
   files containing MEF (multi-exposure-frame) mosaic images.  Also,
   random groups files MUST be described as 'application/fits' and not
   as 'image/fits'.

   A FITS file described with the media type "image/fits" is also valid
   as a file of media type "application/fits".  The choice of
   classification depends on the context and intended usage.

   Recommendations for application writers:

   An application that is intended to handle "image/fits" SHOULD be able
   to provide a user with a manifest of all of the HDUs that are present
   in the file and with all of the keyword/value pairs from each of the
   HDUs.  An application writer MAY choose to ignore HDUs beyond the
   PHDU, but even in this case the application SHOULD be able to present
   the user with the keyword/value pairs from the PHDU.

Allen & Wells                 Informational                    [Page 16]

Internet-Draft              MIME types for FITS               2004-08-26

   Note that an application intended to render "image/fits" for viewing
   by a user has significantly more responsibility than an application
   intended to handle, e.g., "image/tiff" or "image/gif".  FITS data
   arrays contain elements which typically represent the values of a
   physical quantity at some coordinate location.  Consequently they
   need not contain any pixel rendering information in the form of
   transfer functions, and there is no mechanism for color look-up
   tables.  An application SHOULD provide this functionality, either
   statically using a more or less sophisticated algorithm, or
   interactively allowing a user various degrees of choice.

   Furthermore, the elements in a FITS data array may be integers or
   floating-point numbers.  The dynamic range of the data array values
   may exceed that of the display medium and the eye, and their
   distribution may be highly nonuniform.  Logarithmic, square-root, and
   quadratic transfer functions along with histogram equalization
   techniques have proved helpful for rendering FITS data arrays.  Some
   elements of the array may have values which indicate that their data
   are undefined or invalid; these should be rendered distinctly.  Via
   WCS Paper I [WCS1] the standard permits "CTYPEnnn = 'COMPLEX'" to
   assert that a data array contains complex numbers (future revisions
   might admit other elements such as quaternions or general tensors).

   Three-dimensional data arrays (NAXIS=3 with NAXIS1, NAXIS2 and NAXIS3
   > 1) are of special interest.  Applications intended to handle
   "image/fits" MAY default to displaying the first 2D plane of such an
   image cube, or they MAY default to presenting such an image in a
   fashion akin to that used for an animated GIF, or they MAY present
   the data cube as a mosaic of 'thumbnail' images.  Even in the absence
   of WCS indication of a temporal axis the time-lapse movie-looping
   display technique can be effective, and application writers SHOULD
   consider offering it for all three-dimensional arrays.

   An "image/fits" PHDU with NAXIS=1 is describing a one-dimensional
   entity such as a spectrum or a time series.  Applications intended to
   handle "image/fits" MAY default to displaying such an image as a
   graphical plot rather than as a two-dimensional picture with a single
   row.

   An application that cannot handle an image with dimensionality other
   than 2 SHOULD gracefully indicate its limitations to its users when
   it encounters NAXIS=1 or NAXIS=3 cases, while still providing access
   to the keyword/value pairs.

Allen & Wells                 Informational                    [Page 17]

Internet-Draft              MIME types for FITS               2004-08-26

   FITS files with degenerate axes (i.e., one or more NAXISn=1) MAY be
   described as 'image/fits', but the first axes SHOULD be
   non-degenerate (i.e., the degenerate axes SHOULD be the highest
   dimensions).  An algorithm designed to render only two-dimensional
   images will be capable of displaying such an NAXIS=3 or NAXIS=4 FITS
   array that has one or two of the axes consisting of a single pixel,
   and an application writer SHOULD consider coding this capability into
   the application.  Writers of new applications which generate FITS
   files intended to be described as 'image/fits' SHOULD consider using
   the WCSAXES keyword [WCS1] to declare the dimensionality of such
   degenerate axes, so that NAXIS can be used to convey the number of
   non-degenerate axes.

   Magic number(s): "SIMPLE  =                    T"

   Jeff Uphoff of the National Radio Astronomy Observatory (NRAO) has
   contributed database entries for the magic number file which is used
   by the Unix "file" command.  Magic number files with these entries
   are distributed with a variety of Unix-like operating systems.  In
   addition to recognizing a FITS file using the string given above, the
   Uphoff entries also recognize the data type of the pixels in the
   PHDU.

   File extension(s): fits

   This file extension SHOULD NOT be interpreted as a prescription.

   The FITS standard originated in the era when files were stored and
   exchanged via magnetic tape; it does not prescribe any nomenclature
   for files on disk.  Various sites within the FITS community have
   long-established practices where files are presumed to be FITS by
   context.  File extensions used at such sites commonly indicate
   content of the file instead of the data format.

   In the absence of other information it is reasonably safe to presume
   that a file name ending in ".fits" is intended to be a FITS file.
   Nevertheless, there are other commonly used extensions; e.g., ".fit",
   ".fts", and many others not suitable for listing in a media type
   registration.

   Intended usage: Common

   Persons to contact for further information:

   "Steve Allen"     <[email-masked]>
   "Don Wells"       <[email-masked]>

   Author/Change controller:

   "Steve Allen"     <[email-masked]>

   The IAU FITS Working Group may authorize changes to this document.

Allen & Wells                 Informational                    [Page 18]

Internet-Draft              MIME types for FITS               2004-08-26

6. References

6.1 Normative References

   [Require]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [MIME1]     Freed, N.  and N.  Borenstein, "Multipurpose Internet
               Mail Extensions (MIME) Part One: Format of Internet
               Message Bodies", RFC 2045, November 1996.

   [MIME2]     Freed, N.  and N.  Borenstein, "Multipurpose Internet
               Mail Extensions (MIME) Part Two: Media Types",
               RFC 2046, November 1996.

   [MIME4]     Freed, N. and N. Borenstein,  "Multipurpose Internet
               Mail Extensions (MIME) Part Four: Registration
               Procedures", RFC 2048, November 1996.

   [HTTP]      Fielding, R., et al., "Hypertext Transfer Protocol --
               HTTP/1.1", RFC 2616, June 1999.

   [NOST]      Hanisch, R., et al., "Definition of the Flexible
               Image Transport System (FITS)", Astronomy &
               Astrophysics, 376, p. 359, 2001.

   [WCS1]      Greisen, E. and M. Calabretta, "Representations of
               world coordinates in FITS", Astronomy & Astrophysics,
               395, p. 1061, 2002.

   [WCS2]      Calabretta, M. and E. Greisen, "Representations of
               celestial coordinates in FITS", Astronomy &
               Astrophysics, 395, p. 1077, 2002.

6.2 Informative References

   [FITS]      Wells, D., et al., "FITS: A Flexible Image Transport
               System", Astronomy & Astrophysics Supplement, 44,
               p. 363, 1981.

   [GROUPS]    Greisen, E.  and R.  Harten, "An extension of FITS
               for groups of small arrays of data", Astronomy &
               Astrophysics Supplement, 44, p. 371, 1981.

   [XTENSION]  Grosbol, P., et al., "Generalized extensions and
               blocking factors for FITS", Astronomy & Astrophysics
               Supplement, 73, p. 359, 1988.

   [IAUFWG]    McNally, D., ed., "Transactions of the IAU, Vol.
               XXB 1988, Proceedings of the Twentieth General Assembly
               Baltimore 1988", Kluwer Academic, p. 52 (Resolution
               B2), 1988.

Allen & Wells                 Informational                    [Page 19]

Internet-Draft              MIME types for FITS               2004-08-26

   [TABLE]     Harten, R., et al., "The FITS tables extension",
               Astronomy & Astrophysics Supplement, 73, p. 365, 1988.

   [IMAGE]     Ponz, J., et al., "The FITS image extension", Astronomy
               & Astrophysics Supplement, 105, p. 53, 1994.

   [BINTABLE]  Cotton, W., et al., "Binary table extension to FITS",
               Astronomy & Astrophysics Supplement, 113, p. 159, 1995.

   [Remark]    Greisen, E., "FITS: A remarkable achievement in
               information exchange" in "Information Handling in
               Astronomy -- Historical Vistas", A. Heck, ed., Kluwer
               Academic, p. 71, 2003.

   [NVO]       The US National Virtual Observatory,
               http://www.us-vo.org/

   [AstroGrid] The UK AstroGrid, http://www.astrogrid.org/

   [AVO]       The European Astrophysical Virtual Observatory,
               http://www.euro-vo.org/

   [ASU]       Albrecht, M., et al., "Astronomical Server URL",
               http://vizier.u-strasbg.fr/doc/asu.html, 1996.

   [SIAP]      Tody, D., et al., "Simple Image Access Prototype
               Specification", http://www.us-vo.org/pubs/,
               2002.

   [TIFF]      Adobe Systems Incorporated, "TIFF Revision 6.0",
               http://partners.adobe.com/asn/developer/pdfs/tn/TIFF6.pdf
               1992.

   [GeoTIFF]   Ritter, N. and M. Ruth, "GeoTIFF Format Specification",
               http://www.remotesensing.org/geotiff/geotiff.html,
               2000.

Allen & Wells                 Informational                    [Page 20]

Internet-Draft              MIME types for FITS               2004-08-26

7. Security Considerations

   The security considerations of interchanging FITS files are discussed
   above within the text of the IANA registration for each media type.

8. Contributors

   Several individuals have made significant contributions to the
   content and clarity of this text:

      - Francois Ochsenbein  (Observatoire Astronomique de Strasbourg)

      - Clive Davenhall      (Institute for Astronomy of the Royal
                              Observatory Edinburgh)

      - Tom McGlynn          (Laboratory for High Energy Astrophysics of
                              the NASA Goddard Space Flight Center)

      - Lucio Chiappetti     (Milan section of the Italian Istituto di
                              Astrofisica Spaziale e Fisica Cosmica)

      - William Pence        (NASA High Energy Astrophysics Science
                              Archive Research Center)

      - Arnold Rots          (High Energy Astrophysics Division of the
                              Smithsonian Astrophysical Observatory)

      - Doug Tody            (National Radio Astronomy Observatory)

      - Bob Hanisch          (Space Telescope Science Institute)

      - Mark Calabretta      (Australia Telescope National Facility)

9. Acknowledgments

   This document originated when William Joye of the Research and
   Development Group at the Smithsonian Astrophysical Observatory High
   Energy Astrophysics Division discovered many experimental and
   unofficial MIME media types being used by various agencies.

   Jeff Uphoff of the National Radio Astronomy Observatory (NRAO)
   contributed the FITS entries for the magic number file that permits
   the Unix-like "file" command on many systems to identify a FITS file.

   Nelson Zarate verified that the fgread and fgwrite programs are
   able to store hierarchical directories containing files with
   arbitrary MIME media types within a HDU of a FITS file.  The fgread
   and fgwrite programs are part of the FITSUTIL IRAF external package
   written by N.  Zarate, D.  Tody, R.  Seaman at National Optical
   Astronomy Observatory (NOAO), 1999-09.

Allen & Wells                 Informational                    [Page 21]

Internet-Draft              MIME types for FITS               2004-08-26

10. Authors' Addresses

   Steven L. Allen
   UCO/Lick Observatory
   University of California
   Santa Cruz, CA  95064  USA

   Phone: +1 831 459 3046
   E-Mail: [email-masked]

   Donald C. Wells
   National Radio Astronomy Observatory
   520 Edgemont Road
   Charlottesville, Virginia  22903-2475  USA

   Phone: +1 434 296 0277
   E-Mail: [email-masked]

11. Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78 and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

Allen & Wells                 Informational                    [Page 22]

Internet-Draft              MIME types for FITS               2004-08-26

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Expires: 2005-02-26

Allen & Wells                 Informational                    [Page 23]
>From [email-masked]  Mon Aug 30 12:36:06 2004
From: lewis_arise at bumerang.ro (Al Gilman)
Date: Thu Sep 16 09:17:10 2004
Subject: Request for comments for Media Type registration
	ofapplication/ccxml+xml
Message-ID: <[email-masked]>

At 3:03 PM +0900 7/28/04, Martin Duerst wrote:
>At 13:05 04/07/27 -0700, RJ Auburn wrote:
>
>>On 07/21/2004 22:03, "Larry Masinter" <[email-masked]> wrote:
>>
>>>  These comments are as much about the general "IETF MIME type
>>>  registration from W3C recommendation" as they are about this
>>>  particular registration:
>>
>>
>>Martin: Would you be the person to handle/address the general issues?
>
>Yes. For everybody's information, RJ is following the procedure laid
>out
>Because he is the first to do so, this is a very good case to see
>where we have to tweak that description. I have already made two
>additions:
>1) Added a sentence "Make sure that this part of the specification
>    is readable on its own, without the context of the specification."
>    [for further details, a good example is probably better than a
>     lot of explanations]
>2) Added a sentence "To make it easier for your WG to track comments
>    on the Media Type section, you may cross-post the comments list
>    for your specification."
>    [I want to leave this to the group for the moment. They have to
>     show that they addressed comments to the IESG, so having that
>     documented in a last call table may have advantages and
>     disadvantages.]
>
>Also, I'm planning to add some pointers to examples to the above
>description, once we have them. That should make it easier for
>others to do this.
>
>>  > Your translation from HTML to ASCII left out line breaks
>>>  before heading lines, which made your template hard
>>>  to read.
>>
>>If needed I can resubmit a nicer looking version. Let me know...
>
>I guess that can wait for the next time you send something anyway,
>but I hope this will be soon.
>
>>  >> Published specification:
>>>>
>>>>  This media type registration is for CCXML documents as
>>>>  described by this specification.
>>>
>>>  I'm not 100% sure if this is necessary, but I'd expect
>>>  if the template were to appear elsewhere to see
>>>  a bibliographic citation, e.g.,
>>>
>>>  "Voice Browser Call Control: CCXML Version 1.0", W3C
>>>  Working Draft, 30 April 2004, W3C,
>>>
>>>  Is "this specification" (or the whole specification) precise
>>>  enough?  In some other cases, a single W3C recommendation defines
>>>  many different data types. Perhaps it would be useful to
>>>  say, somewhere, e.g., that the MIME type refers to XML bodies that
>>>  conform to the DTD/Schema referenced in Appendix B and C and
>>>  interpreted by the rules in the cited specification.
>>
>>
>>Pointing at the schema/dtd sections seems reasonable.  How is this for text:
>>
>>Published specification:
>>     This media type registration is for XML bodies that
>>     conform to the DTD/Schema referenced in Appendix B and C and
>>     interpreted by the rules this specification
>
>'this specification' -> 'of this specification'
>
>>  >> Person & email address to contact for further information:
>>>>
>>>>  RJ Auburn, <[email-masked]>.
>>>
>>>  Should there be a W3C contact as well?
>>
>>
>>Dave/Max/Martin: Thoughts?
>
>Adding the name of a staff contact or so might be a good idea.
>
>>  >> Intended usage:
>>>>
>>>>  COMMON
>>>>  Author/Change controller:
>>>>
>>>>  The CCXML specification is a work product of the World Wide Web
>>>  Consortium's
>>>>  Voice Browser Working Group. The W3C has change control over these
>>>>  specifications.
>>>
>>>  Or perhaps the W3C contact address should be listed here.
>>
>>Dave/Max/Martin: Thoughts?
>
>The W3C is 'on the Web', not at a particular physical location.
>This kind of wording has been used in some previous registrations,
>and should be okay.

Actually, Martin, the W3C should come up with something better.  This is
a detail of the "life after Rec[ommendation status is achieved]" that I am
not aware we have laid out adequately.

There is a slight problem because the W3C has studiously avoided being
a legal entity which could be identified in standard X.500 terms.

Do you have a technical comment?
W3C technical reports include email addresses where     readers 
should send technical comments.
</quote>

The Consortium has also assiduously avoided promising to answer 
questions about its
utterances, other than that one may post 'comments' in the above 
manner.  Clearly a 'comment'
alleging that there is an inconsistency in the provisions of a 
specification, if read and found
to be accurate, may result in something being added to the errata for 
a document.

I would suggest that the 'comments to' email address be included in 
the contact information
provided in a MIME type registration request.

As far as identifying The Consortium it should suffice to use the URI  as
identification in this context.

It would be helpful, but probably not required by the IETF 
pro-formas, to also allude to the
process for change control by a reference to the W3C Process Document 
identified

Al

>Regards,    Martin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040830/d18c2756/Confidential-0001.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040830/d18c2756/Message-0001.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040830/d18c2756/Terms-0001.htm
>From [email-masked]  Tue Aug 31 13:25:37 2004
From: lewis_arise at bumerang.ro (Al Gilman)
Date: Thu Sep 16 09:17:14 2004
Subject: Request for comments for Media Type registration
	ofapplication/ccxml+xml
Message-ID: <[email-masked]>

At 3:03 PM +0900 7/28/04, Martin Duerst wrote:
>At 13:05 04/07/27 -0700, RJ Auburn wrote:
>
>>On 07/21/2004 22:03, "Larry Masinter" <[email-masked]> wrote:
>>
>>>  These comments are as much about the general "IETF MIME type
>>>  registration from W3C recommendation" as they are about this
>>>  particular registration:
>>
>>
>>Martin: Would you be the person to handle/address the general issues?
>
>Yes. For everybody's information, RJ is following the procedure laid
>out
>Because he is the first to do so, this is a very good case to see
>where we have to tweak that description. I have already made two
>additions:
>1) Added a sentence "Make sure that this part of the specification
>    is readable on its own, without the context of the specification."
>    [for further details, a good example is probably better than a
>     lot of explanations]
>2) Added a sentence "To make it easier for your WG to track comments
>    on the Media Type section, you may cross-post the comments list
>    for your specification."
>    [I want to leave this to the group for the moment. They have to
>     show that they addressed comments to the IESG, so having that
>     documented in a last call table may have advantages and
>     disadvantages.]
>
>Also, I'm planning to add some pointers to examples to the above
>description, once we have them. That should make it easier for
>others to do this.
>
>>  > Your translation from HTML to ASCII left out line breaks
>>>  before heading lines, which made your template hard
>>>  to read.
>>
>>If needed I can resubmit a nicer looking version. Let me know...
>
>I guess that can wait for the next time you send something anyway,
>but I hope this will be soon.
>
>>  >> Published specification:
>>>>
>>>>  This media type registration is for CCXML documents as
>>>>  described by this specification.
>>>
>>>  I'm not 100% sure if this is necessary, but I'd expect
>>>  if the template were to appear elsewhere to see
>>>  a bibliographic citation, e.g.,
>>>
>>>  "Voice Browser Call Control: CCXML Version 1.0", W3C
>>>  Working Draft, 30 April 2004, W3C,
>>>
>>>  Is "this specification" (or the whole specification) precise
>>>  enough?  In some other cases, a single W3C recommendation defines
>>>  many different data types. Perhaps it would be useful to
>>>  say, somewhere, e.g., that the MIME type refers to XML bodies that
>>>  conform to the DTD/Schema referenced in Appendix B and C and
>>>  interpreted by the rules in the cited specification.
>>
>>
>>Pointing at the schema/dtd sections seems reasonable.  How is this for text:
>>
>>Published specification:
>>     This media type registration is for XML bodies that
>>     conform to the DTD/Schema referenced in Appendix B and C and
>>     interpreted by the rules this specification
>
>'this specification' -> 'of this specification'
>
>>  >> Person & email address to contact for further information:
>>>>
>>>>  RJ Auburn, <[email-masked]>.
>>>
>>>  Should there be a W3C contact as well?
>>
>>
>>Dave/Max/Martin: Thoughts?
>
>Adding the name of a staff contact or so might be a good idea.
>
>>  >> Intended usage:
>>>>
>>>>  COMMON
>>>>  Author/Change controller:
>>>>
>>>>  The CCXML specification is a work product of the World Wide Web
>>>  Consortium's
>>>>  Voice Browser Working Group. The W3C has change control over these
>>>>  specifications.
>>>
>>>  Or perhaps the W3C contact address should be listed here.
>>
>>Dave/Max/Martin: Thoughts?
>
>The W3C is 'on the Web', not at a particular physical location.
>This kind of wording has been used in some previous registrations,
>and should be okay.

Actually, Martin, the W3C should come up with something better.  This is
a detail of the "life after Rec[ommendation status is achieved]" that I am
not aware we have laid out adequately.

There is a slight problem because the W3C has studiously avoided being
a legal entity which could be identified in standard X.500 terms.

Do you have a technical comment?
W3C technical reports include email addresses where     readers 
should send technical comments.
</quote>

The Consortium has also assiduously avoided promising to answer 
questions about its
utterances, other than that one may post 'comments' in the above 
manner.  Clearly a 'comment'
alleging that there is an inconsistency in the provisions of a 
specification, if read and found
to be accurate, may result in something being added to the errata for 
a document.

I would suggest that the 'comments to' email address be included in 
the contact information
provided in a MIME type registration request.

As far as identifying The Consortium it should suffice to use the URI  as
identification in this context.

It would be helpful, but probably not required by the IETF 
pro-formas, to also allude to the
process for change control by a reference to the W3C Process Document 
identified

Al

>Regards,    Martin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040831/83549d63/Collection-0001.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040831/83549d63/Confidential-0001.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040831/83549d63/Message-0001.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040831/83549d63/Terms-0001.htm
>From [email-masked]  Mon Aug  9 14:52:00 2004
From: shollenbeck at verisign.com (Hollenbeck, Scott)
Date: Tue Jan  3 16:22:45 2006
Subject: MIME-type Review Request: draft-ietf-avt-rtp-dsr-codecs-03.txt
Message-ID: <[email-masked]>

This is a request for MIME-type review for this document:

http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-dsr-codecs-03.txt

Please send comments to both the ietf-types list and the cc recipients
listed on this message.

Thank you,
-Scott-

From: sla at ucolick.org (Steve Allen)
Date: Tue Jan  3 16:22:48 2006
Subject: MIME Sub-type Registrations for FITS
Message-ID: <[email-masked]>

Greetings.

The FITS Working Group of the International Astronomical Union
has approved the submission of the attached document as
an Internet-Draft in the expectation that it may become
an Informational RFC and result in the registration of the
two MIME media types image/fits and application/fits.

The approval process for this document is visible in the
archives of the IAU FITS Working Group at
http://listmgr.cv.nrao.edu/pipermail/iaufwg/

The call for votes in the IAUFWG is visible at
http://listmgr.cv.nrao.edu/pipermail/iaufwg/2004-July/000200.html

The approval of the document by the IAUFWG is visible at
http://listmgr.cv.nrao.edu/pipermail/iaufwg/2004-August/000212.html

--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
[email-masked]      Voice: +1 831 459 3046     http://www.ucolick.org/~sla
PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93
-------------- next part --------------
Internet-Draft                                                  S. Allen
draft-allen-fitsmime-00.txt                         UCO/Lick Observatory
Category: Informational                                         D. Wells
                                    National Radio Astronomy Observatory
Expires: 2005-02-26                                           2004-08-26

                MIME Sub-type Registrations for FITS

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

   This document may not be modified, and derivative works of it may not
   be created, except to publish it as an RFC and to translate it into
   languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than a "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   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 (2004).  All Rights Reserved.

Abstract

   This document describes the registration of the Multipurpose Internet
   Mail Extensions (MIME) sub-types to be used by the international
   astronomical community for the interchange of FITS files.  The
   encoding is defined by the published FITS standard documents.  The
   FITS format has been in use since 1979, and almost all data from
   astronomical observations are interchanged using FITS.

Allen & Wells                 Informational                     [Page 1]

Internet-Draft              MIME types for FITS               2004-08-26

Table of Contents

   1.  Introduction....................................................2
   2.  Conventions Used in this Document...............................3
   3.  Overview........................................................3
   4.  FITS Definition.................................................3
     4.1  FITS Structure...............................................3
     4.2  History of FITS Features.....................................5
     4.3  Stability of the FITS definition.............................6
     4.4  Portability of FITS files....................................7
     4.5  Application Programming Interfaces to FITS...................8
     4.6  FITS File Conformance Testing................................8
     4.7  Archives That Distribute FITS Files..........................9
   5.  IANA Registration...............................................9
     5.1  application/fits............................................10
     5.2  image/fits..................................................14
   6.  References.....................................................19
     6.1  Normative References........................................19
     6.2  Informative References......................................19
   7.  Security Considerations........................................21
   8.  Contributors...................................................21
   9.  Acknowledgments................................................21
   10.  Authors' Addresses............................................22
   11.  Full Copyright Statement......................................22

1. Introduction

   The FITS file format [FITS] was designed in order to facilitate the
   interchange of astronomical image data between observatories.  FITS
   provides a means of transporting arrays and tables of data and
   keyword/value pairs of metadata.  FITS is defined by standards
   documents that are approved by the International Astronomical Union
   (IAU, http://www.iau.org/) and published in refereed journals.

   Astronomers used the Internet to exchange FITS files before the
   inception of HTTP.  Multiple unofficial media types for FITS files
   [ASU] came into use shortly after the inception of the WWW, and have
   continued in use.  Currently (2004) the international astronomical
   community is engaged in several cooperative efforts (e.g., [NVO],
   [AstroGrid], [AVO]) to produce web services that provide astronomical
   data.  The exchange of FITS files is a fundamental element of the
   prototypes for these web services [SIAP].  The astronomical community
   needs to agree to use one set of media types for FITS files in order
   to promote interoperability of its various services.

   In its simplest form, FITS is used as a means of transporting
   astronomical image data in a raster form along with coordinate
   information and other standard and locally defined metadata.  In such
   applications FITS is much like the well-known TIFF format [TIFF] with
   the addition of the GeoTIFF tags [GeoTIFF].  However, FITS is capable
   of describing a much broader range of data than 2-dimensional
   rasters.  A consensus has developed in the FITS community that two
   media types are needed, one for images and one for all other cases.

Allen & Wells                 Informational                     [Page 2]

Internet-Draft              MIME types for FITS               2004-08-26

2. Conventions Used in this Document

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [Require].

3. Overview

   This document describes the registration of the MIME media sub-types
   "application/fits" and "image/fits".

   In 1988 the International Astronomical Union formed the FITS Working
   Group (IAUFWG) to oversee matters pertaining to the evolution of the
   FITS data format.  The IAUFWG has approved the submission of this
   document and the registration of these two MIME types.

4. FITS Definition

   FITS is defined by a document approved by the International
   Astronomical Union (IAU) and published in the journal Astronomy &
   Astrophysics [NOST].  Conventions for additional keywords used in
   FITS files are proposed by interested parties and negotiated and
   reviewed by ad hoc committees of the FITS community.  If such usage
   of additional keywords is approved by national committees and the
   IAUFWG then they become new reserved keywords in the FITS standard
   and are published in an ongoing series of papers (e.g., [WCS1,
   WCS2]).

   Copies of the standard documents can also be found via:

   http://fits.gsfc.nasa.gov/

   http://archive.stsci.edu/fits/

   http://www.cv.nrao.edu/fits/

   http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html

   While a brief structure and feature description is provided in this
   section as background information, the reader is directed to the FITS
   standards documents to obtain complete feature and technical details.

4.1 FITS Structure

   A FITS file consists of a sequence of one or more header and data
   units (HDUs) optionally followed by special records.  The structure
   of a FITS file is based on blocks with a length of 2880 8-bit bytes
   (23040 bits).  This size was chosen to be evenly divisible by the
   byte and word lengths of all known computer systems.  All FITS files
   have lengths that are integral multiples of this block size.

Allen & Wells                 Informational                     [Page 3]

Internet-Draft              MIME types for FITS               2004-08-26

   Each FITS header consists of a sequence of one or more 2880-byte
   blocks that hold 36 80-character records (36*80=2880).  The records
   consist of ASCII keyword/value pairs plus optional comments.  The
   character set is the 7-bit printing ASCII codes, including the ASCII
   space.  In particular, the control codes CR, LF, FF, TAB and NUL are
   not used in FITS headers.  The keywords are up to 8 characters in
   length.  Some keywords are mandatory, and their meaning is rigidly
   prescribed.  Among these are keywords that describe the structure and
   size of the subsequent data array.  The standard reserves other
   keywords for the purpose of conveying specifically defined items of
   metadata.  Keywords that are neither mandatory nor reserved may be
   inserted with semantics that are defined by local conventions.  (Some
   local conventions have later been adopted into standardized
   practice.)  The end of the header is signified by a block containing
   the keyword "END".  A simple example of a FITS header for a digital
   image, using only keywords that were specified in the initial FITS
   Agreement of March 1979 [FITS], is:

            1         2         3         4         5         6
   1234567890123456789012345678901234567890123456789012345678901234567..

   SIMPLE  =                    T / file does conform to FITS standard
   BITPIX  =                   16 / 16-bit twos-complement pixel values
   NAXIS   =                    2 / 2-dimensional image
   NAXIS1  =                  512 / first axis length
   NAXIS2  =                  512 / second axis length
   COMMENT  -----------------------------------------------------
   COMMENT   FITS (Flexible Image Transport System) format is defined
   COMMENT   in 'Astronomy and Astrophysics', volume 376, page 359;
   COMMENT   bibcode: 2001A&A...376..359H
   COMMENT  -----------------------------------------------------
   ORIGIN  = 'Lick Observatory   ' /
   DATE    = '2003-11-22T05:23:45' / when this file was written
   END
   (these 13 records are followed by 23 80-character records of ASCII
   spaces,  to pad the header block to the 2880-byte FITS block size)

   The first keyword/value pair, SIMPLE=T, is the signature of FITS; all
   FITS files begin with these characters.  BITPIX is the second keyword
   of all FITS files; legal values for it are 8, 16, 32, -32 and -64.
   NAXIS is the third keyword of all FITS files; legal values for it are
   0 to 999.  NAXIS=0 is legal, and implies that there is no image data
   matrix associated with the header (and the NAXISi keywords must not
   be present); this value is common for files which will be given the
   media type 'application/fits' as discussed in section 5.1 of this
   document.  NAXIS=2 is the value most often used for files which will
   be given the media type 'image/fits', as discussed in section 5.2 of
   this document (NAXIS=3 FITS images are also common).  The COMMENT
   records will be ignored by FITS reading software, but are used here
   to specify the precise journal citation for the FITS standard, an
   item of information which is important for archiving on timescales of

Allen & Wells                 Informational                     [Page 4]

Internet-Draft              MIME types for FITS               2004-08-26

   decades.  The ORIGIN keyword is commonly used in FITS files to encode
   the name of the institution where the file was produced.  The DATE
   keyword is used to convey the time-stamp for the file (keyword
   DATE-OBS is used to convey observation start times).  FITS headers
   commonly contain a vast variety of additional keywords used to encode
   metadata.  In particular, a digital image header will often include
   keywords to specify the precise celestial coordinates of the pixels
   of the 2-D matrix, using conventions which became part of the FITS
   standard in 2002 (see [WCS2]).  Finally, the above example
   demonstrates how, in addition to the COMMENT records, 60% of the
   bytes in keyword=value records in FITS headers are reserved for
   comments.  Although the simple header example above is contained in
   only one FITS block, multi-block FITS headers are commonly
   interchanged.

   Following each header is a data unit that consists of a sequence of
   zero or more 2880-byte blocks.  In accordance with the description in
   the keywords of their header, these blocks contain an N-dimensional
   data array, optionally followed by other small groups of array data.
   In most cases the data array represents either an N-dimensional array
   of image pixel values or a 2-dimensional array of tabular data.

   Following the HDUs a FITS file may contain zero or more 2880-byte
   blocks of special records.  The standard does not specify anything
   about their content.  (This convention for special records is not
   known to have been used for any purpose other than prototyping new
   elements of the standard, such as random groups and BINTABLE.)

   The initial HDU in a FITS file is known as the primary HDU (PHDU);
   any subsequent HDU is known as an extension HDU (XHDU).  The keyword
   content of the PHDU is distinct (a PHDU requires a slight alteration
   before it can become an XHDU, and most types of XHDU cannot become a
   PHDU).  A PHDU may have a data array consisting of zero elements, and
   this will often be the case for FITS files intended to communicate
   tables and multiple images.  An XHDU may be one of several standard
   types, or it may be another conforming type.  Standard types of XHDU
   include "IMAGE" (containing an N-dimensional data array similar in
   most respects to the PHDU), "TABLE" (containing a 2-dimensional table
   of ASCII character data), and "BINTABLE" (containing a 2-dimensional
   table of binary data whose elements may themselves be
   multi-dimensional arrays).

4.2 History of FITS Features

   In 1981 the original definition of FITS described a single HDU
   containing one multi-dimensional image array [FITS], as illustrated
   by the sample header shown in section 4.1.  Subsequent agreements
   have used the original framework of HDUs and keyword/value pairs to
   extend FITS while preserving the validity of all existing files.
   FITS now has standard means of describing multiple arrays of image
   data and/or multiple tables of numeric and character information.

Allen & Wells                 Informational                     [Page 5]

Internet-Draft              MIME types for FITS               2004-08-26

   Brief highlights of the history of FITS

    - 1979: Initial FITS Agreement and first interchange of files

    - 1980: Random groups convention developed

    - 1981: Published original (single HDU) definition [FITS]

    - 1981: Published random groups definition [GROUPS]

    - 1982: Formally endorsed by the IAU

    - 1988: Defined rules for multiple HDUs [XTENSION]

    - 1988: FITS Working Group established by IAU [IAUFWG]

    - 1988: Extended to include ASCII tables [TABLE]

    - 1990: Extended to include IEEE floating-point data

    - 1994: Extended to multiple image arrays [IMAGE]

    - 1995: Extended to binary tables [BINTABLE]

    - 1997: Adopted a Y2K-compliant date format

    - 2001: Reiterated existing standard in one paper [NOST]

    - 2002: Approved conventions for world coordinates [WCS1, WCS2]

4.3 Stability of the FITS definition

   After the adoption of FITS by the IAU in 1982, some in the emerging
   community of FITS users realized that there would be tension between
   the need for archival stability and the need for evolution.  In order
   to satisfy both of these requirements they set up a controlled
   parliamentary process.  At the time of the Generalized Extensions
   Agreement [XTENSION], the meta-agreement that controls the evolution
   of FITS, the FITS community adopted the guiding principle "Once FITS,
   always FITS".  Under this rule no change may be made to FITS which
   invalidates existing files.  Changes to the FITS standard occur only
   after action by the IAU FITS Working Group (FWG).  The FWG acts only
   after approval by regional working groups that coordinate FITS
   activity in various parts of the world.

   FITS has been adopted as the archival format for image data and
   interferometric data obtained by many ground-based observatories and
   for all data from many spacecraft.  Many astrophysical archives store
   their data in FITS format, and most astronomical catalog data has
   been transcribed into FITS files.  The many terabytes of data in
   these archives contribute to the stability of the FITS standard.

Allen & Wells                 Informational                     [Page 6]

Internet-Draft              MIME types for FITS               2004-08-26

4.4 Portability of FITS files

   Eric Greisen, one of the authors of the original document [FITS],
   relates that in 1979

      The first FITS files were written by a PL/I program on an IBM 360
      under OS/MFT (32-bit, twos-complement numbers and 8-bit EBCDIC
      characters) and were read by a Fortran program executing on a CDC
      6400 under SCOPE (60-bit, ones-complement numbers and 6-bit
      "Display Code" characters).[Remark]

   Subsequent evolution of computing hardware and FITS over 25 years
   have not degraded this ability to transfer the data content.

   The structure of FITS files is extremely general, and this
   necessarily complements the nature of astronomical data.  FITS is
   used to store observations of the entire electromagnetic spectrum
   from radio to gamma rays, from ground-based observatories and from
   spacecraft.  FITS is also used to communicate physical properties
   other than radiation intensity; these may be inferred from
   observations or calculated by theoretical models.  The pedigree of
   data in a FITS file typically varies among disciplines; FITS may be
   used to store raw and uncalibrated data, or completely reduced and
   calibrated data, or both.  Nevertheless, the FITS standard provides
   that the syntactic content of the data and metadata are unambiguously
   available to posterity.

   Observatories have developed numerous local conventions for the
   storage and transfer of data peculiar to their instrumentation and
   purview.  Application software for handling FITS files from different
   regions of the electromagnetic spectrum has been largely disjoint.
   For a FITS file which consists of multiple HDUs there are no widely
   established conventions governing the meaning of, interrelations
   between, and suggested use of the data sets.  Recognition of any
   local conventions used for FITS data has often been based on
   heuristics of the additional (non-standard) keyword/value pairs.
   Fully understanding the semantic content of a FITS file usually
   requires an external data dictionary.

Allen & Wells                 Informational                     [Page 7]

Internet-Draft              MIME types for FITS               2004-08-26

4.5 Application Programming Interfaces to FITS

   Although the definition of FITS is expressed in terms of the bit
   content of the files, there are widely-supported application
   programming interfaces (APIs) which simplify the task of manipulating
   FITS files.  Interfaces exist for many languages and operating
   systems.  A partial list of APIs follows:

   CFITSIO      http://heasarc.gsfc.nasa.gov/fitsio/
   fitsTcl      http://heasarc.gsfc.nasa.gov/ftools/fv/fitsTcl_home.html
   WCSLIB       http://www.atnf.csiro.au/people/mcalabre/WCS/
   PyFITS       http://www.stsci.edu/resources/software_hardware/pyfits
   WCSTools     http://tdc-www.harvard.edu/software/wcstools/
   FUNTOOLS     http://hea-www.harvard.edu/RD/funtools/
   IDLASTRO     http://idlastro.gsfc.nasa.gov/
   fitsy        http://cfa-www.harvard.edu/~john/fitsy/
   IUEDAC       http://archive.stsci.edu/iue/iuedacfits.html
   Mathematica  http://documents.wolfram.com/v5/Built-inFunctions/
                       GraphicsAndSound/ImportAndExport/
                       AdditionalInformation/Import.html
   MatLab       http://www.mathworks.com/access/helpdesk/help/techdoc/
                       ref/fitsread.shtml?cmdname=fitsread

   Current lists of more APIs can be found at
   http://fits.gsfc.nasa.gov/fits_libraries.html

   List of applications that use FITS are found in the IANA
   registrations of the media types.

4.6 FITS File Conformance Testing

   FITS files can be tested for conformance to the Definition of FITS
   rules [NOST, WCS1, WCS2] with an application named 'fitsverify',
   which is available at

   http://heasarc.gsfc.nasa.gov/docs/software/ftools/fitsverify/

   in the form of executable binary files for Solaris, Linux, and
   Windows platforms, as well as in source code.  Although 'fitsverify'
   has not been endorsed by the IAUFWG, users should be aware that the
   designer of the program was the Secretary of the Technical Panel
   which produced the published FITS standard [NOST].

Allen & Wells                 Informational                     [Page 8]

Internet-Draft              MIME types for FITS               2004-08-26

4.7 Archives That Distribute FITS Files

   As noted in Section 4.3 of this RFC, massive (multi-terabyte) data
   archives which contain and/or distribute FITS files contribute to the
   stability of the FITS standard.  There are numerous publicly
   available archives of FITS files derived from both space and
   ground-based observations that span the entire range of the
   electromagnetic spectrum from radio to gamma-ray wavelengths.
   Examples of such archives, in no particular order, include:

   Telescope(s)   URLs for archive access
   ------------   ------------------------------------------------------
   KPNO,CTIO,..   http://iraf.noao.edu/projects/stb/archive.html
   VLT,HST,..     http://archive.eso.org/
   Subaru         http://moka.nao.ac.jp/
   SDSS           http://www.sdss.org/dr1/
   CFHT           http://cadcwww.dao.nrc.ca/cfht/cfht.html
   VLA,VLBA,GBT   http://e2e.aoc.nrao.edu/archive/archive_describe.html
   HST,MAST       http://archive.stsci.edu/
   HEASARC        http://heasarc.gsfc.nasa.gov/w3browse/
   Chandra        http://cxc.harvard.edu/cda/
   LaPalma        http://archive.ast.cam.ac.uk/ingarch/
   BIMA           http://bimaarch.ncsa.uiuc.edu/
   Keck-DEIMOS    http://archive.deep.ucolick.org/
   ComptonGRO     http://cossc.gsfc.nasa.gov/archive/index.html
   Spitzer,..     http://www.ipac.caltech.edu/
   AAT            http://www.aao.gov.au/archive/
   HIPASS         http://www.atnf.csiro.au/research/multibeam/
                          multibeam.html
   JCMT           http://salish.dao.nrc.ca:8080/jcmt/intro.html
   COBE,WMAP      http://lambda.gsfc.nasa.gov/
   EVN            http://www.jive.nl/archive/scripts/listarch.php
   Gemini         http://gemini.ast.cam.ac.uk/sciops/data/dataIndex.html
   XMM-Newton     http://xmm.vilspa.esa.es/external/xmm_data_acc/xsa/

5. IANA Registration

   The general nature of the full FITS standard requires the use of the
   media type "application/fits".  Nevertheless, the principal intent
   for a great many FITS files is to convey a single data array in the
   PHDU, and such arrays are very often 2-dimensional images.  Several
   common image viewing applications already display single-HDU FITS
   files, and the prototypes for virtual observatory projects specify
   that data provided by web services be conveyed by the data array in
   the PHDU.  These uses justify the registration of a second media
   type, namely "image/fits", for files which use the subset of the
   standard described by the original FITS standard paper [FITS].

Allen & Wells                 Informational                     [Page 9]

Internet-Draft              MIME types for FITS               2004-08-26

   We note that the media type "image/gif" [MIME2] admits raster images
   which are three dimensional, because animated GIF images contain two
   spatial dimensions and one temporal dimension.  We note that the
   media types "image/vnd.dwg" and "image/vnd.dxf" admit data which
   include three dimensional vectors and curves as well as objects
   created using constructive solid geometry.  Following these
   precedents for the "image" media type, we specify that "image/fits"
   MAY be used to describe FITS PHDUs that have other than two
   dimensions.  We expect that the majority of files described as
   "image/fits" will have two-dimensional (NAXIS=2) PHDUs.

5.1 application/fits

   To: [email-masked]
   Subject: Registration of Standard MIME Media type application/fits

   MIME media type name: application

   MIME subtype name: fits

   Required parameters: none

   Optional parameters: none

   Encoding considerations: binary

   FITS files can be quite large.  When transferred via HTTP it may be
   efficient for the transaction to make use of content-coding or
   transfer-coding values such as "gzip", "compress", or "deflate".

   Security considerations:

   FITS provides a means of transporting arrays and tables of data and
   keyword/value pairs of metadata.  The standard FITS keywords are
   either mandatory or reserved.  Mandatory keywords provide information
   necessary for correct interpretation of the data; reserved keywords
   merely provide standard bits of metadata.  As such, the current
   standard FITS keywords do not pose security risks.

   A FITS file author may insert additional keywords with semantics that
   are not described by the standard.  Parties exchanging FITS files may
   employ locally defined conventions that use various keywords and
   their values to induce actions on the part of the recipient.  There
   are existing local conventions where such keywords are used to
   request the reading of other files and/or URIs.  There are other
   local conventions where such keywords are used to modify the state of
   a telescope and/or instrument.  The security implications of local
   conventions such as these SHOULD be analyzed by the parties employing
   them.

Allen & Wells                 Informational                    [Page 10]

Internet-Draft              MIME types for FITS               2004-08-26

   Interoperability considerations:

   FITS files have been successfully transported between wildly
   different computers since 1979.  The difficulty most likely to be
   encountered by a FITS application is inability to acquire the
   computational resources required by a very large FITS file.

   Published specification:

   The specification for this content type is published as a series of
   papers in refereed astronomical journals:

   Hanisch, R., et al., "Definition of the Flexible Image Transport
   System (FITS)", Astronomy & Astrophysics, 376, p. 359, 2001.

   Greisen, E. and M. Calabretta, "Representations of world coordinates
   in FITS", Astronomy & Astrophysics, 395, p. 1061, 2002.

   Calabretta, M. and E. Greisen, "Representations of celestial
   coordinates in FITS", Astronomy & Astrophysics, 395, p. 1077, 2002.

   Copies of these specifications can also be found via:

   http://fits.gsfc.nasa.gov/
   http://archive.stsci.edu/fits/
   http://www.cv.nrao.edu/fits/
   http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html

   Applications that use this media type:

   There are many astronomical image viewing and data reduction
   applications including, but not limited to, the following list:

   IRAF     http://iraf.noao.edu/
   AIPS     http://www.aoc.nrao.edu/aips/
   AIPS++   http://aips2.nrao.edu/
   MIDAS    http://www.eso.org/projects/esomidas/
   ds9      http://hea-www.harvard.edu/RD/ds9/
   fv       http://heasarc.gsfc.nasa.gov/ftools/fv/
   Aladin   http://aladin.u-strasbg.fr/
   Starlink http://star-www.rl.ac.uk/
   Miriad   http://bima.astro.umd.edu/miriad/
   STSDAS   http://www.stsci.edu/resources/software_hardware/stsdas
   PROS     http://hea-www.harvard.edu/PROS/pros.html
   CIAO     http://asc.harvard.edu/ciao/
   XANADU   http://heasarc.gsfc.nasa.gov/docs/xanadu/xanadu.html
   HESSI    http://hesperia.gsfc.nasa.gov/ssw/hessi/doc/
   FITSview http://www.nrao.edu/software/fitsview/
   XMM-SAS  http://xmm.vilspa.esa.es/external/xmm_sw_cal/sas_frame.shtml

   At the present time many of these applications are not designed to
   support use as viewers of 'application/fits' files in association
   with web browsers.

Allen & Wells                 Informational                    [Page 11]

Internet-Draft              MIME types for FITS               2004-08-26

   Additional information:

   A FITS file described with the media type "application/fits" SHOULD
   conform to the published standards for FITS files as determined by
   convention and agreement within the international FITS community.  No
   other constraints are placed on the content of a file described as
   "application/fits".

   A FITS file described with the media type "application/fits" may have
   an arbitrary number of conforming extension header and data units
   (XHDUs) that follow its mandatory primary header and data unit
   (PHDU).  The XHDUs may be one of the standard types ("IMAGE",
   "TABLE", and "BINTABLE") or any other type that satisfies the
   'Requirements for Conforming Extensions' (section 4.4.1 of [NOST]).
   The PHDU or any "IMAGE" XHDU may contain zero to 999 dimensions with
   zero or more pixels along each dimension.

   The PHDU may use the random groups convention, in which the dimension
   of the first axis is zero and the keywords GROUPS, PCOUNT and GCOUNT
   appear in the header.  NAXIS1=0 and GROUPS=T is the signature of
   random groups; see section 7 of the Definition of FITS paper [NOST].

   Recommendations for application writers:

   An application intended to handle "application/fits" SHOULD be able
   to provide a user with a manifest of all of the HDUs that are present
   in the file and with all of the keyword/value pairs from each of the
   HDUs.

   An application intended to handle "application/fits" SHOULD be
   prepared to encounter XHDUs that contain either ASCII or binary
   tables, and to provide a user with access to their elements.

   An application which can modify FITS files or retrieve FITS files
   from an external service SHOULD be capable of writing such files to a
   local storage medium.

   Complete interpretation of the meaning and intended use of the data
   in each of the HDUs typically requires the use of heuristics that
   attempt to ascertain which local conventions were used by the author
   of the FITS file.

   As examples, files with media type "application/fits" might contain
   any of the following contents:

     - An empty PHDU (containing zero data elements) followed by a table
       HDU that contains a catalog of celestial objects.

     - An empty PHDU followed by a table HDU that encodes a series of
       time-tagged photon events from an exposure using an X-ray
       detector.

Allen & Wells                 Informational                    [Page 12]

Internet-Draft              MIME types for FITS               2004-08-26

     - An empty PHDU followed by a series of IMAGE HDUs containing data
       from an exposure taken by a mosaic of CCD detectors.

     - An empty PHDU followed by a series of table HDUs that contain a
       snapshot of the state of a relational database.

     - A PHDU containing a single image along with keyword/value pairs
       of metadata.

     - A PHDU with NAXIS1=0 and GROUPS=T followed by random groups data
       records of complex fringe visibilities

   Magic number(s): "SIMPLE  =                    T"

   Jeff Uphoff of the National Radio Astronomy Observatory (NRAO) has
   contributed database entries for the magic number file which is used
   by the Unix "file" command.  Magic number files with these entries
   are distributed with a variety of Unix-like operating systems.  In
   addition to recognizing a FITS file using the string given above, the
   Uphoff entries also recognize the data type of the pixels in the
   PHDU.

   File extension(s): fits

   This file extension SHOULD NOT be interpreted as a prescription.

   The FITS standard originated in the era when files were stored and
   exchanged via magnetic tape; it does not prescribe any nomenclature
   for files on disk.  Various sites within the FITS community have
   long-established practices where files are presumed to be FITS by
   context.  File extensions used at such sites commonly indicate
   content of the file instead of the data format.

   In the absence of other information it is reasonably safe to presume
   that a file name ending in ".fits" is intended to be a FITS file.
   Nevertheless, there are other commonly used extensions; e.g., ".fit",
   ".fts", and many others not suitable for listing in a media type
   registration.

   Intended usage: Common

   Persons to contact for further information:

   "Steve Allen"     <[email-masked]>
   "Don Wells"       <[email-masked]>

   Author/Change controller:

   "Steve Allen" <[email-masked]>

   The IAU FITS Working Group may authorize changes to this document.

Allen & Wells                 Informational                    [Page 13]

Internet-Draft              MIME types for FITS               2004-08-26

5.2 image/fits

   To: [email-masked]
   Subject: Registration of Standard MIME Media type image/fits

   MIME media type name: image

   MIME subtype name: fits

   Required parameters: none

   Optional parameters: none

   Encoding considerations: binary

   FITS files can be quite large.  When transferred via HTTP it may be
   efficient for the transaction to make use of content-coding or
   transfer-coding values such as "gzip", "compress", or "deflate".

   Security considerations:

   FITS provides a means of transporting arrays and tables of data and
   keyword/value pairs of metadata.  The standard FITS keywords are
   either mandatory or reserved.  Mandatory keywords provide information
   necessary for correct interpretation of the data; reserved keywords
   merely provide standard bits of metadata.  As such, the current
   standard FITS keywords do not pose security risks.

   A FITS file author may insert additional keywords with semantics that
   are not described by the standard.  Parties exchanging FITS files may
   employ locally defined conventions that use various keywords and
   their values to induce actions on the part of the recipient.  There
   are existing local conventions where such keywords are used to
   request the reading of other files and/or URIs.  There are other
   local conventions where such keywords are used to modify the state of
   a telescope and/or instrument.  The security implications of local
   conventions such as these SHOULD be analyzed by the parties employing
   them.

   Interoperability considerations:

   FITS files have been successfully transported between wildly
   different computers since 1979.  The difficulty most likely to be
   encountered by a FITS application is inability to acquire the
   computational resources required by a very large FITS file.

Allen & Wells                 Informational                    [Page 14]

Internet-Draft              MIME types for FITS               2004-08-26

   Published specification:

   The specification for this content type is published as a series of
   papers in refereed astronomical journals:

   Hanisch, R., et al., "Definition of the Flexible Image Transport
   System (FITS)", Astronomy & Astrophysics, 376, p. 359, 2001.

   Greisen, E.  and M.  Calabretta, "Representations of world
   coordinates in FITS", Astronomy & Astrophysics, 395, p.  1061, 2002.

   Calabretta, M. and E. Greisen, "Representations of celestial
   coordinates in FITS", Astronomy & Astrophysics, 395, p. 1077, 2002.

   Copies of these specifications can also be found via:

   http://fits.gsfc.nasa.gov/
   http://archive.stsci.edu/fits/
   http://www.cv.nrao.edu/fits/
   http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html

   Applications that use this media type:

   There are many astronomical image viewing and data reduction
   applications including, but not limited to, the following list:

   IRAF     http://iraf.noao.edu/
   AIPS     http://www.aoc.nrao.edu/aips/
   AIPS++   http://aips2.nrao.edu/
   MIDAS    http://www.eso.org/projects/esomidas/
   ds9      http://hea-www.harvard.edu/RD/ds9/
   fv       http://heasarc.gsfc.nasa.gov/ftools/fv/
   Aladin   http://aladin.u-strasbg.fr/
   Starlink http://star-www.rl.ac.uk/
   Miriad   http://bima.astro.umd.edu/miriad/
   STSDAS   http://www.stsci.edu/resources/software_hardware/stsdas
   PROS     http://hea-www.harvard.edu/PROS/pros.html
   CIAO     http://asc.harvard.edu/ciao/
   XANADU   http://heasarc.gsfc.nasa.gov/docs/xanadu/xanadu.html
   HESSI    http://hesperia.gsfc.nasa.gov/ssw/hessi/doc/
   FITSview http://www.nrao.edu/software/fitsview/
   XMM-SAS  http://xmm.vilspa.esa.es/external/xmm_sw_cal/sas_frame.shtml

   Non-astronomical FITS image display applications include:

   netpbm          http://netpbm.sourceforge.net/
   gimp            http://www.gimp.org/
   IDL             http://www.rsinc.com/
   ImageMagick     http://www.imagemagick.com/
   Mathematica     http://www.wolfram.com/
   MatLab          http://www.mathworks.com/
   xv              http://www.trilon.com/xv/xv.html

Allen & Wells                 Informational                    [Page 15]

Internet-Draft              MIME types for FITS               2004-08-26

   There are also two FITS plug-ins for Adobe Photoshop
   (http://www.adobe.com/products/photoshop/), available at
   http://astroshed.com/fitsplug/fitsplug.htm and
   http://www.spacetelescope.org/projects/fits_liberator/

   At the present time many of the applications listed above are not
   designed to support use as viewers of 'image/fits' files in
   association with web browsers.

   Additional information:

   A FITS file described with the media type "image/fits" SHOULD have a
   PHDU with positive integer values for the NAXIS and NAXISn keywords,
   and hence SHOULD contain at least one pixel.  Files with 4 or more
   non-degenerate axes (NAXISn>1) SHOULD be described as
   'application/fits', not as 'image/fits'.  (In rare cases it may be
   appropriate to describe a NULL image -- a dataless container for FITS
   keywords, with NAXIS=0 or NAXISn=0 -- or an image with 4+
   non-degenerate axes as 'image/fits' but this usage is discouraged
   because such files may confuse simple image viewer applications.)

   FITS files declared as 'image/fits' MAY also have one or more
   conforming XHDUs following their PHDUs.  These extension HDUs MAY
   contain standard, non-linear, world coordinate system (WCS)
   information in the form of tables or images.  The extension HDUs MAY
   also contain other, non-standard metadata pertaining to the image in
   the PHDU in the forms of keywords and tables.

   A FITS file described with the media type "image/fits" SHOULD be
   principally intended to communicate the single data array in the
   PHDU.  This means that "image/fits" SHOULD NOT be applied to FITS
   files containing MEF (multi-exposure-frame) mosaic images.  Also,
   random groups files MUST be described as 'application/fits' and not
   as 'image/fits'.

   A FITS file described with the media type "image/fits" is also valid
   as a file of media type "application/fits".  The choice of
   classification depends on the context and intended usage.

   Recommendations for application writers:

   An application that is intended to handle "image/fits" SHOULD be able
   to provide a user with a manifest of all of the HDUs that are present
   in the file and with all of the keyword/value pairs from each of the
   HDUs.  An application writer MAY choose to ignore HDUs beyond the
   PHDU, but even in this case the application SHOULD be able to present
   the user with the keyword/value pairs from the PHDU.

Allen & Wells                 Informational                    [Page 16]

Internet-Draft              MIME types for FITS               2004-08-26

   Note that an application intended to render "image/fits" for viewing
   by a user has significantly more responsibility than an application
   intended to handle, e.g., "image/tiff" or "image/gif".  FITS data
   arrays contain elements which typically represent the values of a
   physical quantity at some coordinate location.  Consequently they
   need not contain any pixel rendering information in the form of
   transfer functions, and there is no mechanism for color look-up
   tables.  An application SHOULD provide this functionality, either
   statically using a more or less sophisticated algorithm, or
   interactively allowing a user various degrees of choice.

   Furthermore, the elements in a FITS data array may be integers or
   floating-point numbers.  The dynamic range of the data array values
   may exceed that of the display medium and the eye, and their
   distribution may be highly nonuniform.  Logarithmic, square-root, and
   quadratic transfer functions along with histogram equalization
   techniques have proved helpful for rendering FITS data arrays.  Some
   elements of the array may have values which indicate that their data
   are undefined or invalid; these should be rendered distinctly.  Via
   WCS Paper I [WCS1] the standard permits "CTYPEnnn = 'COMPLEX'" to
   assert that a data array contains complex numbers (future revisions
   might admit other elements such as quaternions or general tensors).

   Three-dimensional data arrays (NAXIS=3 with NAXIS1, NAXIS2 and NAXIS3
   > 1) are of special interest.  Applications intended to handle
   "image/fits" MAY default to displaying the first 2D plane of such an
   image cube, or they MAY default to presenting such an image in a
   fashion akin to that used for an animated GIF, or they MAY present
   the data cube as a mosaic of 'thumbnail' images.  Even in the absence
   of WCS indication of a temporal axis the time-lapse movie-looping
   display technique can be effective, and application writers SHOULD
   consider offering it for all three-dimensional arrays.

   An "image/fits" PHDU with NAXIS=1 is describing a one-dimensional
   entity such as a spectrum or a time series.  Applications intended to
   handle "image/fits" MAY default to displaying such an image as a
   graphical plot rather than as a two-dimensional picture with a single
   row.

   An application that cannot handle an image with dimensionality other
   than 2 SHOULD gracefully indicate its limitations to its users when
   it encounters NAXIS=1 or NAXIS=3 cases, while still providing access
   to the keyword/value pairs.

Allen & Wells                 Informational                    [Page 17]

Internet-Draft              MIME types for FITS               2004-08-26

   FITS files with degenerate axes (i.e., one or more NAXISn=1) MAY be
   described as 'image/fits', but the first axes SHOULD be
   non-degenerate (i.e., the degenerate axes SHOULD be the highest
   dimensions).  An algorithm designed to render only two-dimensional
   images will be capable of displaying such an NAXIS=3 or NAXIS=4 FITS
   array that has one or two of the axes consisting of a single pixel,
   and an application writer SHOULD consider coding this capability into
   the application.  Writers of new applications which generate FITS
   files intended to be described as 'image/fits' SHOULD consider using
   the WCSAXES keyword [WCS1] to declare the dimensionality of such
   degenerate axes, so that NAXIS can be used to convey the number of
   non-degenerate axes.

   Magic number(s): "SIMPLE  =                    T"

   Jeff Uphoff of the National Radio Astronomy Observatory (NRAO) has
   contributed database entries for the magic number file which is used
   by the Unix "file" command.  Magic number files with these entries
   are distributed with a variety of Unix-like operating systems.  In
   addition to recognizing a FITS file using the string given above, the
   Uphoff entries also recognize the data type of the pixels in the
   PHDU.

   File extension(s): fits

   This file extension SHOULD NOT be interpreted as a prescription.

   The FITS standard originated in the era when files were stored and
   exchanged via magnetic tape; it does not prescribe any nomenclature
   for files on disk.  Various sites within the FITS community have
   long-established practices where files are presumed to be FITS by
   context.  File extensions used at such sites commonly indicate
   content of the file instead of the data format.

   In the absence of other information it is reasonably safe to presume
   that a file name ending in ".fits" is intended to be a FITS file.
   Nevertheless, there are other commonly used extensions; e.g., ".fit",
   ".fts", and many others not suitable for listing in a media type
   registration.

   Intended usage: Common

   Persons to contact for further information:

   "Steve Allen"     <[email-masked]>
   "Don Wells"       <[email-masked]>

   Author/Change controller:

   "Steve Allen"     <[email-masked]>

   The IAU FITS Working Group may authorize changes to this document.

Allen & Wells                 Informational                    [Page 18]

Internet-Draft              MIME types for FITS               2004-08-26

6. References

6.1 Normative References

   [Require]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [MIME1]     Freed, N.  and N.  Borenstein, "Multipurpose Internet
               Mail Extensions (MIME) Part One: Format of Internet
               Message Bodies", RFC 2045, November 1996.

   [MIME2]     Freed, N.  and N.  Borenstein, "Multipurpose Internet
               Mail Extensions (MIME) Part Two: Media Types",
               RFC 2046, November 1996.

   [MIME4]     Freed, N. and N. Borenstein,  "Multipurpose Internet
               Mail Extensions (MIME) Part Four: Registration
               Procedures", RFC 2048, November 1996.

   [HTTP]      Fielding, R., et al., "Hypertext Transfer Protocol --
               HTTP/1.1", RFC 2616, June 1999.

   [NOST]      Hanisch, R., et al., "Definition of the Flexible
               Image Transport System (FITS)", Astronomy &
               Astrophysics, 376, p. 359, 2001.

   [WCS1]      Greisen, E. and M. Calabretta, "Representations of
               world coordinates in FITS", Astronomy & Astrophysics,
               395, p. 1061, 2002.

   [WCS2]      Calabretta, M. and E. Greisen, "Representations of
               celestial coordinates in FITS", Astronomy &
               Astrophysics, 395, p. 1077, 2002.

6.2 Informative References

   [FITS]      Wells, D., et al., "FITS: A Flexible Image Transport
               System", Astronomy & Astrophysics Supplement, 44,
               p. 363, 1981.

   [GROUPS]    Greisen, E.  and R.  Harten, "An extension of FITS
               for groups of small arrays of data", Astronomy &
               Astrophysics Supplement, 44, p. 371, 1981.

   [XTENSION]  Grosbol, P., et al., "Generalized extensions and
               blocking factors for FITS", Astronomy & Astrophysics
               Supplement, 73, p. 359, 1988.

   [IAUFWG]    McNally, D., ed., "Transactions of the IAU, Vol.
               XXB 1988, Proceedings of the Twentieth General Assembly
               Baltimore 1988", Kluwer Academic, p. 52 (Resolution
               B2), 1988.

Allen & Wells                 Informational                    [Page 19]

Internet-Draft              MIME types for FITS               2004-08-26

   [TABLE]     Harten, R., et al., "The FITS tables extension",
               Astronomy & Astrophysics Supplement, 73, p. 365, 1988.

   [IMAGE]     Ponz, J., et al., "The FITS image extension", Astronomy
               & Astrophysics Supplement, 105, p. 53, 1994.

   [BINTABLE]  Cotton, W., et al., "Binary table extension to FITS",
               Astronomy & Astrophysics Supplement, 113, p. 159, 1995.

   [Remark]    Greisen, E., "FITS: A remarkable achievement in
               information exchange" in "Information Handling in
               Astronomy -- Historical Vistas", A. Heck, ed., Kluwer
               Academic, p. 71, 2003.

   [NVO]       The US National Virtual Observatory,
               http://www.us-vo.org/

   [AstroGrid] The UK AstroGrid, http://www.astrogrid.org/

   [AVO]       The European Astrophysical Virtual Observatory,
               http://www.euro-vo.org/

   [ASU]       Albrecht, M., et al., "Astronomical Server URL",
               http://vizier.u-strasbg.fr/doc/asu.html, 1996.

   [SIAP]      Tody, D., et al., "Simple Image Access Prototype
               Specification", http://www.us-vo.org/pubs/,
               2002.

   [TIFF]      Adobe Systems Incorporated, "TIFF Revision 6.0",
               http://partners.adobe.com/asn/developer/pdfs/tn/TIFF6.pdf
               1992.

   [GeoTIFF]   Ritter, N. and M. Ruth, "GeoTIFF Format Specification",
               http://www.remotesensing.org/geotiff/geotiff.html,
               2000.

Allen & Wells                 Informational                    [Page 20]

Internet-Draft              MIME types for FITS               2004-08-26

7. Security Considerations

   The security considerations of interchanging FITS files are discussed
   above within the text of the IANA registration for each media type.

8. Contributors

   Several individuals have made significant contributions to the
   content and clarity of this text:

      - Francois Ochsenbein  (Observatoire Astronomique de Strasbourg)

      - Clive Davenhall      (Institute for Astronomy of the Royal
                              Observatory Edinburgh)

      - Tom McGlynn          (Laboratory for High Energy Astrophysics of
                              the NASA Goddard Space Flight Center)

      - Lucio Chiappetti     (Milan section of the Italian Istituto di
                              Astrofisica Spaziale e Fisica Cosmica)

      - William Pence        (NASA High Energy Astrophysics Science
                              Archive Research Center)

      - Arnold Rots          (High Energy Astrophysics Division of the
                              Smithsonian Astrophysical Observatory)

      - Doug Tody            (National Radio Astronomy Observatory)

      - Bob Hanisch          (Space Telescope Science Institute)

      - Mark Calabretta      (Australia Telescope National Facility)

9. Acknowledgments

   This document originated when William Joye of the Research and
   Development Group at the Smithsonian Astrophysical Observatory High
   Energy Astrophysics Division discovered many experimental and
   unofficial MIME media types being used by various agencies.

   Jeff Uphoff of the National Radio Astronomy Observatory (NRAO)
   contributed the FITS entries for the magic number file that permits
   the Unix-like "file" command on many systems to identify a FITS file.

   Nelson Zarate verified that the fgread and fgwrite programs are
   able to store hierarchical directories containing files with
   arbitrary MIME media types within a HDU of a FITS file.  The fgread
   and fgwrite programs are part of the FITSUTIL IRAF external package
   written by N.  Zarate, D.  Tody, R.  Seaman at National Optical
   Astronomy Observatory (NOAO), 1999-09.

Allen & Wells                 Informational                    [Page 21]

Internet-Draft              MIME types for FITS               2004-08-26

10. Authors' Addresses

   Steven L. Allen
   UCO/Lick Observatory
   University of California
   Santa Cruz, CA  95064  USA

   Phone: +1 831 459 3046
   E-Mail: [email-masked]

   Donald C. Wells
   National Radio Astronomy Observatory
   520 Edgemont Road
   Charlottesville, Virginia  22903-2475  USA

   Phone: +1 434 296 0277
   E-Mail: [email-masked]

11. Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78 and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

Allen & Wells                 Informational                    [Page 22]

Internet-Draft              MIME types for FITS               2004-08-26

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Expires: 2005-02-26

Allen & Wells                 Informational                    [Page 23]
>From [email-masked]  Mon Aug 30 12:36:06 2004
From: lewis_arise at bumerang.ro (Al Gilman)
Date: Tue Jan  3 16:22:48 2006
Subject: Request for comments for Media Type registration
	ofapplication/ccxml+xml
Message-ID: <[email-masked]>

At 3:03 PM +0900 7/28/04, Martin Duerst wrote:
>At 13:05 04/07/27 -0700, RJ Auburn wrote:
>
>>On 07/21/2004 22:03, "Larry Masinter" <[email-masked]> wrote:
>>
>>>  These comments are as much about the general "IETF MIME type
>>>  registration from W3C recommendation" as they are about this
>>>  particular registration:
>>
>>
>>Martin: Would you be the person to handle/address the general issues?
>
>Yes. For everybody's information, RJ is following the procedure laid
>out
>Because he is the first to do so, this is a very good case to see
>where we have to tweak that description. I have already made two
>additions:
>1) Added a sentence "Make sure that this part of the specification
>    is readable on its own, without the context of the specification."
>    [for further details, a good example is probably better than a
>     lot of explanations]
>2) Added a sentence "To make it easier for your WG to track comments
>    on the Media Type section, you may cross-post the comments list
>    for your specification."
>    [I want to leave this to the group for the moment. They have to
>     show that they addressed comments to the IESG, so having that
>     documented in a last call table may have advantages and
>     disadvantages.]
>
>Also, I'm planning to add some pointers to examples to the above
>description, once we have them. That should make it easier for
>others to do this.
>
>>  > Your translation from HTML to ASCII left out line breaks
>>>  before heading lines, which made your template hard
>>>  to read.
>>
>>If needed I can resubmit a nicer looking version. Let me know...
>
>I guess that can wait for the next time you send something anyway,
>but I hope this will be soon.
>
>>  >> Published specification:
>>>>
>>>>  This media type registration is for CCXML documents as
>>>>  described by this specification.
>>>
>>>  I'm not 100% sure if this is necessary, but I'd expect
>>>  if the template were to appear elsewhere to see
>>>  a bibliographic citation, e.g.,
>>>
>>>  "Voice Browser Call Control: CCXML Version 1.0", W3C
>>>  Working Draft, 30 April 2004, W3C,
>>>
>>>  Is "this specification" (or the whole specification) precise
>>>  enough?  In some other cases, a single W3C recommendation defines
>>>  many different data types. Perhaps it would be useful to
>>>  say, somewhere, e.g., that the MIME type refers to XML bodies that
>>>  conform to the DTD/Schema referenced in Appendix B and C and
>>>  interpreted by the rules in the cited specification.
>>
>>
>>Pointing at the schema/dtd sections seems reasonable.  How is this for text:
>>
>>Published specification:
>>     This media type registration is for XML bodies that
>>     conform to the DTD/Schema referenced in Appendix B and C and
>>     interpreted by the rules this specification
>
>'this specification' -> 'of this specification'
>
>>  >> Person & email address to contact for further information:
>>>>
>>>>  RJ Auburn, <[email-masked]>.
>>>
>>>  Should there be a W3C contact as well?
>>
>>
>>Dave/Max/Martin: Thoughts?
>
>Adding the name of a staff contact or so might be a good idea.
>
>>  >> Intended usage:
>>>>
>>>>  COMMON
>>>>  Author/Change controller:
>>>>
>>>>  The CCXML specification is a work product of the World Wide Web
>>>  Consortium's
>>>>  Voice Browser Working Group. The W3C has change control over these
>>>>  specifications.
>>>
>>>  Or perhaps the W3C contact address should be listed here.
>>
>>Dave/Max/Martin: Thoughts?
>
>The W3C is 'on the Web', not at a particular physical location.
>This kind of wording has been used in some previous registrations,
>and should be okay.

Actually, Martin, the W3C should come up with something better.  This is
a detail of the "life after Rec[ommendation status is achieved]" that I am
not aware we have laid out adequately.

There is a slight problem because the W3C has studiously avoided being
a legal entity which could be identified in standard X.500 terms.

Do you have a technical comment?
W3C technical reports include email addresses where     readers 
should send technical comments.
</quote>

The Consortium has also assiduously avoided promising to answer 
questions about its
utterances, other than that one may post 'comments' in the above 
manner.  Clearly a 'comment'
alleging that there is an inconsistency in the provisions of a 
specification, if read and found
to be accurate, may result in something being added to the errata for 
a document.

I would suggest that the 'comments to' email address be included in 
the contact information
provided in a MIME type registration request.

As far as identifying The Consortium it should suffice to use the URI  as
identification in this context.

It would be helpful, but probably not required by the IETF 
pro-formas, to also allude to the
process for change control by a reference to the W3C Process Document 
identified

Al

>Regards,    Martin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20040830/d18c2756/Confidential-0002.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20040830/d18c2756/Message-0002.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20040830/d18c2756/Terms-0002.htm
>From [email-masked]  Tue Aug 31 13:25:37 2004
From: lewis_arise at bumerang.ro (Al Gilman)
Date: Tue Jan  3 16:22:48 2006
Subject: Request for comments for Media Type registration
	ofapplication/ccxml+xml
Message-ID: <[email-masked]>

At 3:03 PM +0900 7/28/04, Martin Duerst wrote:
>At 13:05 04/07/27 -0700, RJ Auburn wrote:
>
>>On 07/21/2004 22:03, "Larry Masinter" <[email-masked]> wrote:
>>
>>>  These comments are as much about the general "IETF MIME type
>>>  registration from W3C recommendation" as they are about this
>>>  particular registration:
>>
>>
>>Martin: Would you be the person to handle/address the general issues?
>
>Yes. For everybody's information, RJ is following the procedure laid
>out
>Because he is the first to do so, this is a very good case to see
>where we have to tweak that description. I have already made two
>additions:
>1) Added a sentence "Make sure that this part of the specification
>    is readable on its own, without the context of the specification."
>    [for further details, a good example is probably better than a
>     lot of explanations]
>2) Added a sentence "To make it easier for your WG to track comments
>    on the Media Type section, you may cross-post the comments list
>    for your specification."
>    [I want to leave this to the group for the moment. They have to
>     show that they addressed comments to the IESG, so having that
>     documented in a last call table may have advantages and
>     disadvantages.]
>
>Also, I'm planning to add some pointers to examples to the above
>description, once we have them. That should make it easier for
>others to do this.
>
>>  > Your translation from HTML to ASCII left out line breaks
>>>  before heading lines, which made your template hard
>>>  to read.
>>
>>If needed I can resubmit a nicer looking version. Let me know...
>
>I guess that can wait for the next time you send something anyway,
>but I hope this will be soon.
>
>>  >> Published specification:
>>>>
>>>>  This media type registration is for CCXML documents as
>>>>  described by this specification.
>>>
>>>  I'm not 100% sure if this is necessary, but I'd expect
>>>  if the template were to appear elsewhere to see
>>>  a bibliographic citation, e.g.,
>>>
>>>  "Voice Browser Call Control: CCXML Version 1.0", W3C
>>>  Working Draft, 30 April 2004, W3C,
>>>
>>>  Is "this specification" (or the whole specification) precise
>>>  enough?  In some other cases, a single W3C recommendation defines
>>>  many different data types. Perhaps it would be useful to
>>>  say, somewhere, e.g., that the MIME type refers to XML bodies that
>>>  conform to the DTD/Schema referenced in Appendix B and C and
>>>  interpreted by the rules in the cited specification.
>>
>>
>>Pointing at the schema/dtd sections seems reasonable.  How is this for text:
>>
>>Published specification:
>>     This media type registration is for XML bodies that
>>     conform to the DTD/Schema referenced in Appendix B and C and
>>     interpreted by the rules this specification
>
>'this specification' -> 'of this specification'
>
>>  >> Person & email address to contact for further information:
>>>>
>>>>  RJ Auburn, <[email-masked]>.
>>>
>>>  Should there be a W3C contact as well?
>>
>>
>>Dave/Max/Martin: Thoughts?
>
>Adding the name of a staff contact or so might be a good idea.
>
>>  >> Intended usage:
>>>>
>>>>  COMMON
>>>>  Author/Change controller:
>>>>
>>>>  The CCXML specification is a work product of the World Wide Web
>>>  Consortium's
>>>>  Voice Browser Working Group. The W3C has change control over these
>>>>  specifications.
>>>
>>>  Or perhaps the W3C contact address should be listed here.
>>
>>Dave/Max/Martin: Thoughts?
>
>The W3C is 'on the Web', not at a particular physical location.
>This kind of wording has been used in some previous registrations,
>and should be okay.

Actually, Martin, the W3C should come up with something better.  This is
a detail of the "life after Rec[ommendation status is achieved]" that I am
not aware we have laid out adequately.

There is a slight problem because the W3C has studiously avoided being
a legal entity which could be identified in standard X.500 terms.

Do you have a technical comment?
W3C technical reports include email addresses where     readers 
should send technical comments.
</quote>

The Consortium has also assiduously avoided promising to answer 
questions about its
utterances, other than that one may post 'comments' in the above 
manner.  Clearly a 'comment'
alleging that there is an inconsistency in the provisions of a 
specification, if read and found
to be accurate, may result in something being added to the errata for 
a document.

I would suggest that the 'comments to' email address be included in 
the contact information
provided in a MIME type registration request.

As far as identifying The Consortium it should suffice to use the URI  as
identification in this context.

It would be helpful, but probably not required by the IETF 
pro-formas, to also allude to the
process for change control by a reference to the W3C Process Document 
identified

Al

>Regards,    Martin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20040831/83549d63/Collection-0002.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20040831/83549d63/Confidential-0002.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20040831/83549d63/Message-0002.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20040831/83549d63/Terms-0002.htm

From: LMM at acm.org (Larry Masinter)
Date: Tue Aug 24 18:58:22 2004
Subject: draft-freed-mime-p4-04 is apparently superseded by..
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

I didn't see a LAST CALL or a Protocol Action

http://www1.ietf.org/mail-archive/web/ietf-announce/current/index.html

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jeff Hodges
> Sent: Saturday, August 21, 2004 12:10 PM
> To: IETF Types vetting list
> Subject: draft-freed-mime-p4-04 is apparently superseded by..
> 
> draft-freed-mime-p4-05
> http://www.ietf.org/internet-drafts/draft-freed-mime-p4-05.txt
> 
> draft-freed-media-type-reg-01
> http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt
> 
> 
> MartinD or whomever might want to update their very nice page..
> 
>   How to Register a Media Type with IANA (for the IETF tree)
>   http://www.w3.org/2002/06/registering-mediatype.html
> 
> 
> thanks,
> 
> JeffH
> 

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:46 2006
Subject: draft-freed-mime-p4-04 is apparently superseded by..
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

I didn't see a LAST CALL or a Protocol Action

http://www1.ietf.org/mail-archive/web/ietf-announce/current/index.html

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jeff Hodges
> Sent: Saturday, August 21, 2004 12:10 PM
> To: IETF Types vetting list
> Subject: draft-freed-mime-p4-04 is apparently superseded by..
> 
> draft-freed-mime-p4-05
> http://www.ietf.org/internet-drafts/draft-freed-mime-p4-05.txt
> 
> draft-freed-media-type-reg-01
> http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt
> 
> 
> MartinD or whomever might want to update their very nice page..
> 
>   How to Register a Media Type with IANA (for the IETF tree)
>   http://www.w3.org/2002/06/registering-mediatype.html
> 
> 
> thanks,
> 
> JeffH
> 

From: LMM at acm.org (Larry Masinter)
Date: Tue Aug 24 18:53:46 2004
Subject: Pre review of 3GPP MIME type for RTP payload format
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Thanks, I now understand. The main thing is that
SDP takes the MIME type and uses the top level type
for signaling.

I wonder, though, whether you might instead register
these things as "application", add a parameter, e.g.,
"embedded-type", and then change the mapping
between MIME types and SDP descriptions such that

application/whatever;embedded-type="video" 
  =>   m=video

so as to avoid having to register N types for
every wrapper mechanism.

Larry

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:46 2006
Subject: Pre review of 3GPP MIME type for RTP payload format
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Thanks, I now understand. The main thing is that
SDP takes the MIME type and uses the top level type
for signaling.

I wonder, though, whether you might instead register
these things as "application", add a parameter, e.g.,
"embedded-type", and then change the mapping
between MIME types and SDP descriptions such that

application/whatever;embedded-type="video" 
  =>   m=video

so as to avoid having to register N types for
every wrapper mechanism.

Larry

From: mario at erphesfurt.de (Mario Salzer)
Date: Tue Jan  3 16:22:46 2006
Subject: [PHP-DEV] Re: Registration of MIME media type application/vnd.php.serialized
Message-ID: <[email-masked]>

Martin Duerst <[email-masked]> schrieb am 24.08.04 08:24:08:
> [...]
> What are 'arbitrary non-printable characters, binary octets'?
> Does iso-8859-1 allow the encoding of arbitrary non-printable
> characters? Does iso-8859-1 encode binary octets? Is it possible
> in this format to serialize data that is another encoding than
> iso-8859-1?
> 
> My advice: Please remove any mention of iso-8859-1 from this
>             draft, it doesn't belong here.

Thank you, Martin!  I remove that again (just wanted to make it a
bit more informative here), and it was wrong anyhow - since it is a
charset-less data format, and the contained strings could even be
in different character sets each.

mario

________________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

From: duerst at w3.org (Martin Duerst)
Date: Tue Aug 24 07:23:51 2004
Subject: Registration of MIME media type application/vnd.php.serialized
In-Reply-To: <[email-masked]>
Message-ID: <4.2.0.58.J.20040824140603.05ac1308@localhost>

Hello Mario,

Just one comment:

At 06:32 04/08/24 +0200, Mario Salzer wrote:
>This vendor tree MIME type registration application discusses the data
>format emitted by PHPs "serialize()". It is no longer in use only within
>there; some independent implementations exist (evtl. becoming an exchange
>format).

>    Encoding considerations: BINARY
>
>       As per current use, contents assigned this MIME Type should be
>       considered to be in the ISO-8859-1 (Latin-1) character set, so
>       that they also may contain arbitrary non-printable characters,
>       binary octets.
>
>       Transport channels not capable of handling raw 8 bit without data
>       corruption SHOULD therefore apply a Transfer-Encoding of "base64"
>       or something similar.

Some thought-provoking (hopefully) questions:

What are 'arbitrary non-printable characters, binary octets'?
Does iso-8859-1 allow the encoding of arbitrary non-printable
characters? Does iso-8859-1 encode binary octets? Is it possible
in this format to serialize data that is another encoding than
iso-8859-1?

My advice: Please remove any mention of iso-8859-1 from this
            draft, it doesn't belong here.

Regards,    Martin.
>From [email-masked]  Tue Aug 24 16:52:50 2004
From: mario at erphesfurt.de (Mario Salzer)
Date: Tue Aug 24 16:53:11 2004
Subject: [PHP-DEV] Re: Registration of MIME media type
	application/vnd.php.serialized
Message-ID: <[email-masked]>

Martin Duerst <[email-masked]> schrieb am 24.08.04 08:24:08:
> [...]
> What are 'arbitrary non-printable characters, binary octets'?
> Does iso-8859-1 allow the encoding of arbitrary non-printable
> characters? Does iso-8859-1 encode binary octets? Is it possible
> in this format to serialize data that is another encoding than
> iso-8859-1?
> 
> My advice: Please remove any mention of iso-8859-1 from this
>             draft, it doesn't belong here.

Thank you, Martin!  I remove that again (just wanted to make it a
bit more informative here), and it was wrong anyhow - since it is a
charset-less data format, and the contained strings could even be
in different character sets each.

mario

________________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:46 2006
Subject: Registration of MIME media type application/vnd.php.serialized
In-Reply-To: <[email-masked]>
Message-ID: <4.2.0.58.J.20040824140603.05ac1308@localhost>

Hello Mario,

Just one comment:

At 06:32 04/08/24 +0200, Mario Salzer wrote:
>This vendor tree MIME type registration application discusses the data
>format emitted by PHPs "serialize()". It is no longer in use only within
>there; some independent implementations exist (evtl. becoming an exchange
>format).

>    Encoding considerations: BINARY
>
>       As per current use, contents assigned this MIME Type should be
>       considered to be in the ISO-8859-1 (Latin-1) character set, so
>       that they also may contain arbitrary non-printable characters,
>       binary octets.
>
>       Transport channels not capable of handling raw 8 bit without data
>       corruption SHOULD therefore apply a Transfer-Encoding of "base64"
>       or something similar.

Some thought-provoking (hopefully) questions:

What are 'arbitrary non-printable characters, binary octets'?
Does iso-8859-1 allow the encoding of arbitrary non-printable
characters? Does iso-8859-1 encode binary octets? Is it possible
in this format to serialize data that is another encoding than
iso-8859-1?

My advice: Please remove any mention of iso-8859-1 from this
            draft, it doesn't belong here.

Regards,    Martin.

From: mario at erphesfurt.de (Mario Salzer)
Date: Tue Aug 24 06:34:07 2004
Subject: Registration of MIME media type application/vnd.php.serialized
Message-ID: <[email-masked]>

This vendor tree MIME type registration application discusses the data
format emitted by PHPs "serialize()". It is no longer in use only within
there; some independent implementations exist (evtl. becoming an exchange
format).

Now that doesn't require a MIME Type per se, but people also started
pushing data in this format through the wires ("me too!").  See also
"PHP-RPC" in [http://geri.cc.fer.hr/~ivoras/web2/papers/phprpc.pdf]
-- not the best example, but at least highlights the necessarity of
a MIME Type - else people go by text/html.

* I guess by RFC2048 the PHP group [//php.net] should have filed this
  rather, but if they had any interest in it they'd already done long
  before.  The vendor name was more accurately "zend" or "phpnet", but
  simply "application/vnd.php.serialized" looks much better.

* Not all too sure if this MIME subtype should have the trailing 'd'
  or simply be called "/vnd.php.serialize".  The "/...d" version however
  seems to match better with "/x-www-form-urlencoded".

* I've included an as-short-as-possible description, cause Google didn't
  found anything worth getting referenced, and I'm really not aware of
  an official format spec.

* Btw, "Person & email address to contact for further information" could
  be a mailing list instead, couldn't it?

hope the wording is 'good enough' for a vnd. subtype :)
mario

   ---------------------------------------------------------------------

   MIME media type name: application

   MIME subtype name: vnd.php.serialized

   Required parameters: NONE

   Optional parameters:

      version=x.y.z

         SHOULD be added in responses (not in Accept: headers [RFC2295])
         to indicate which PHP interpreter version the data was
         compacted by. This is useful to identify and eventually work
         around bugs (format violations) from earlier implementations.

   Encoding considerations: BINARY

      As per current use, contents assigned this MIME Type should be
      considered to be in the ISO-8859-1 (Latin-1) character set, so
      that they also may contain arbitrary non-printable characters,
      binary octets.

      Transport channels not capable of handling raw 8 bit without data
      corruption SHOULD therefore apply a Transfer-Encoding of "base64"
      or something similar.

   Security considerations:

      Implementations SHOULDN'T attempt to reproduce more complex data
      types like objects, file descriptors, function bytecode and
      pointers, because most of this was typically of little use if the
      received data came from a remote machine or even from a different
      programming language.
      For optimal security only the basic data types are to be extracted
      and messages fully be rejected as soon as unknown data type
      identifiers were detected.

      Strongly typed languages with fixed-length variable data storage
      should additionally take care not to expand entities of the format
      described herein beyond memory boundaries; even if none of the
      mentioned types is that difficult to decipher.

   Interoperability considerations:

      The specified format is meant to transport data in a machine-
      independent representation, and is especially freed from byte-
      ordering issues, because all integer types pass in string
      representation. However, there is no surety that the described
      data representation could be used by every possible system,
      especially since it originally was made for use by interpreted
      languages only.

   Published specification:

      To date there is no openly published specification of this data
      representation format. For reference the original implementation
      in [http://cvs.php.net/php-src/ext/standard/var.c#click-display]
      or even better the Perl implementation by Scott Hurring available
      under [http://hurring.com/code/perl/serialize/] can be reviewed.

      A terse documentation of how the basic data types are to be
      encoded is however included here.

      Format description:

         Data is compacted into string representation by bailing out
         chunks containing a type identifier (one letter) an optional
         length/count field (for strings and arrays) and an optional
         value (optional because the NULL/undef type does not require
         one for obvious reasons), all separated by colons and ended
         with a semicolon in most cases.

            <app/vnd.php.serialized#TEXT> = (<data>) *1

            <data> = ( <undef> | <boolean> | <int> | <float>
                       | <string> | <hash> | <strangethings> )

            <undef> = 'N;'

            <boolean> = ( 'b:0;' | 'b:1;' )

            <int> = 'i:' ['-'] <digit>*1 ';'

            <float> = 'd:' ['-'] <digit>*1 '.' <digit>*1 ';'

            <string> = 's:' ( <LENGTH> ) <:"> <text> <";>

               <text> is the string this entity represents after
               serialization. It has exactly <LENGTH> characters and is
               enclosed here by two quote marks. No escaping is to be
               applied, and the receiver shouldn't have to decode it.

            <hash> = 'a:' ( <COUNT> ) ':{' (<data> <data>)*COUNT '}'

               Where <COUNT> is a positive integer (as string) matching
               the number of key<data>+value<data> pairs in between the
               curly braces.
               As an exception the string representation of an array or
               hash does not carry a final semicolon (unlike all basic
               data types).

         Other known data type identifiers are "O" for objects, "R" for
         references and "r" for object references. They are not further
         mentioned here, because they are of little use for exchanging
         data across servers as outlined in the Security considerations
         section.

   Applications which use this media type:

      [http://www.php.net/]
      PHP interpreter with original implementation

      [http://hurring.com/code/perl/serialize/]
      Perl 'serialize.pm' by Scott Hurring and others

      [http://php.net/serialize#41948]
      serialize methods for Ecma/JavaScript types by Iv?n Montes

   Additional information:

      Magic numbers: NONE
      File extensions: NONE
      Macintosh File Type Codes: NONE
      Object Identifiers or OIDs: NONE

   Person & email address to contact for further information:

      Mario Salzer
      <[email-masked]>

   Intended usage: COMMON

      This data format is in heavy use for temporarily storing data to
      disk to keep it beyond a single application run.
      Recently it also started to get used for transportation of data
      via HTTP, as lightweight alternative to SOAP and also XML-RPC.

      By including the original representation types of transcoded data,
      it can be used advantageous to "multipart/form-data" and of course
      the more simple "application/x-www-form-urlencoded". It's not only
      much simpler and faster due to less requirements on escaping, but
      also indirectly allows for validation (data types).

   Author/Change controller:

      Mario Salzer
      <[email-masked]>

      Since this registration happened on deputy of the vendor,
      it's only senseful to transfer 'change control' to
      <[email-masked]> on request.

From: mario at erphesfurt.de (Mario Salzer)
Date: Tue Jan  3 16:22:46 2006
Subject: Registration of MIME media type application/vnd.php.serialized
Message-ID: <[email-masked]>

This vendor tree MIME type registration application discusses the data
format emitted by PHPs "serialize()". It is no longer in use only within
there; some independent implementations exist (evtl. becoming an exchange
format).

Now that doesn't require a MIME Type per se, but people also started
pushing data in this format through the wires ("me too!").  See also
"PHP-RPC" in [http://geri.cc.fer.hr/~ivoras/web2/papers/phprpc.pdf]
-- not the best example, but at least highlights the necessarity of
a MIME Type - else people go by text/html.

* I guess by RFC2048 the PHP group [//php.net] should have filed this
  rather, but if they had any interest in it they'd already done long
  before.  The vendor name was more accurately "zend" or "phpnet", but
  simply "application/vnd.php.serialized" looks much better.

* Not all too sure if this MIME subtype should have the trailing 'd'
  or simply be called "/vnd.php.serialize".  The "/...d" version however
  seems to match better with "/x-www-form-urlencoded".

* I've included an as-short-as-possible description, cause Google didn't
  found anything worth getting referenced, and I'm really not aware of
  an official format spec.

* Btw, "Person & email address to contact for further information" could
  be a mailing list instead, couldn't it?

hope the wording is 'good enough' for a vnd. subtype :)
mario

   ---------------------------------------------------------------------

   MIME media type name: application

   MIME subtype name: vnd.php.serialized

   Required parameters: NONE

   Optional parameters:

      version=x.y.z

         SHOULD be added in responses (not in Accept: headers [RFC2295])
         to indicate which PHP interpreter version the data was
         compacted by. This is useful to identify and eventually work
         around bugs (format violations) from earlier implementations.

   Encoding considerations: BINARY

      As per current use, contents assigned this MIME Type should be
      considered to be in the ISO-8859-1 (Latin-1) character set, so
      that they also may contain arbitrary non-printable characters,
      binary octets.

      Transport channels not capable of handling raw 8 bit without data
      corruption SHOULD therefore apply a Transfer-Encoding of "base64"
      or something similar.

   Security considerations:

      Implementations SHOULDN'T attempt to reproduce more complex data
      types like objects, file descriptors, function bytecode and
      pointers, because most of this was typically of little use if the
      received data came from a remote machine or even from a different
      programming language.
      For optimal security only the basic data types are to be extracted
      and messages fully be rejected as soon as unknown data type
      identifiers were detected.

      Strongly typed languages with fixed-length variable data storage
      should additionally take care not to expand entities of the format
      described herein beyond memory boundaries; even if none of the
      mentioned types is that difficult to decipher.

   Interoperability considerations:

      The specified format is meant to transport data in a machine-
      independent representation, and is especially freed from byte-
      ordering issues, because all integer types pass in string
      representation. However, there is no surety that the described
      data representation could be used by every possible system,
      especially since it originally was made for use by interpreted
      languages only.

   Published specification:

      To date there is no openly published specification of this data
      representation format. For reference the original implementation
      in [http://cvs.php.net/php-src/ext/standard/var.c#click-display]
      or even better the Perl implementation by Scott Hurring available
      under [http://hurring.com/code/perl/serialize/] can be reviewed.

      A terse documentation of how the basic data types are to be
      encoded is however included here.

      Format description:

         Data is compacted into string representation by bailing out
         chunks containing a type identifier (one letter) an optional
         length/count field (for strings and arrays) and an optional
         value (optional because the NULL/undef type does not require
         one for obvious reasons), all separated by colons and ended
         with a semicolon in most cases.

            <app/vnd.php.serialized#TEXT> = (<data>) *1

            <data> = ( <undef> | <boolean> | <int> | <float>
                       | <string> | <hash> | <strangethings> )

            <undef> = 'N;'

            <boolean> = ( 'b:0;' | 'b:1;' )

            <int> = 'i:' ['-'] <digit>*1 ';'

            <float> = 'd:' ['-'] <digit>*1 '.' <digit>*1 ';'

            <string> = 's:' ( <LENGTH> ) <:"> <text> <";>

               <text> is the string this entity represents after
               serialization. It has exactly <LENGTH> characters and is
               enclosed here by two quote marks. No escaping is to be
               applied, and the receiver shouldn't have to decode it.

            <hash> = 'a:' ( <COUNT> ) ':{' (<data> <data>)*COUNT '}'

               Where <COUNT> is a positive integer (as string) matching
               the number of key<data>+value<data> pairs in between the
               curly braces.
               As an exception the string representation of an array or
               hash does not carry a final semicolon (unlike all basic
               data types).

         Other known data type identifiers are "O" for objects, "R" for
         references and "r" for object references. They are not further
         mentioned here, because they are of little use for exchanging
         data across servers as outlined in the Security considerations
         section.

   Applications which use this media type:

      [http://www.php.net/]
      PHP interpreter with original implementation

      [http://hurring.com/code/perl/serialize/]
      Perl 'serialize.pm' by Scott Hurring and others

      [http://php.net/serialize#41948]
      serialize methods for Ecma/JavaScript types by Iv?n Montes

   Additional information:

      Magic numbers: NONE
      File extensions: NONE
      Macintosh File Type Codes: NONE
      Object Identifiers or OIDs: NONE

   Person & email address to contact for further information:

      Mario Salzer
      <[email-masked]>

   Intended usage: COMMON

      This data format is in heavy use for temporarily storing data to
      disk to keep it beyond a single application run.
      Recently it also started to get used for transportation of data
      via HTTP, as lightweight alternative to SOAP and also XML-RPC.

      By including the original representation types of transcoded data,
      it can be used advantageous to "multipart/form-data" and of course
      the more simple "application/x-www-form-urlencoded". It's not only
      much simpler and faster due to less requirements on escaping, but
      also indirectly allows for validation (data types).

   Author/Change controller:

      Mario Salzer
      <[email-masked]>

      Since this registration happened on deputy of the vendor,
      it's only senseful to transfer 'change control' to
      <[email-masked]> on request.

From: Jeff.Hodges at Sun.COM (Jeff Hodges)
Date: Mon Aug 23 22:25:50 2004
Subject: DRAFT Registration of MIME media type application/samlmetadata+xml
Message-ID: <[email-masked]>

comments appreciated...

thanks,
JeffH
-----

<NOTE:
Registration of MIME media type application/samlmetadata+xml
sstc-saml-2.0-application-samlmetadata-registration-00
Jeff Hodges <[email-masked]>
23-Aug-2004

This document is intended to be included in
sstc-saml-metadata-2.0-cd-02 (ie the next time [SAMLv2Meta] is
rev'd), as an appendix.

Please see http://www.w3.org/2002/06/registering-mediatype.html for
an overview of the intricities involved when a non-IETF organization
registers a MIME media type in the "standards tree" (aka "IETF
tree").

The below registration material is intended to satisfy the
requirements stated in draft-freed-media-type-reg-01.txt (which
superseded draft-freed-mime-p4-04.txt).

This "NOTE" is intended to be removed upon copying this document's
content into [SAMLv2Meta].

Acknowledgments: Thanks to Ned Freed and Larry Masinter for their
comments on a draft of a related registration. The security
considerations section leverages that of
http://www.iana.org/assignments/media-types/application/vnd.paos+xml,
by John Kemp.
 >

To: [email-masked]
Subject: Registration of MIME media type application/samlmetadata+xml

Introduction
      This document defines a MIME media type --
      application/samlmetadata+xml -- for use with the XML
      serialization of Security Assertion Markup Language metadata.

      SAML is a work product of the OASIS Security Services Technical
      Committee [SSTC]. The SAML specifications define XML-based
      constructs with which one may make, and convey, security
      assertions. Using SAML, one can assert that an authentication
      event pertaining to some subject has occurred and convey said
      assertion to a relying party, for example.

      SAML profiles require agreements between system entities
      regarding identifiers, binding support, endpoints, certificates,
      keys, and so forth. Such information is treated as metadata by
      SAML v2.0. [SAMLv2Meta] specifies this metadata, as well as
      specifying metadata publication and resolution mechanisms. If
      the publishing protocol permits MIME-based identification of
      content types, then use of the application/samlmetadata+xml MIME
      media type is required.

MIME media type name: application

MIME subtype name: samlmetadata+xml

Required parameters: none

Optional parameters: charset
      Same as charset parameter of application/xml [RFC3023].

Encoding considerations:
      Same as for application/xml [RFC3023].

Security considerations:
      Per their specification, samlmetadata+xml typed objects do not
      contain executable content. However, these objects are XML-based
      [XML], and thus they have all of the general security
      considerations presented in section 10 of [RFC3023].

      SAML metadata [SAMLv2Meta] contains information whose integrity
      and authenticity is important ? identity provider and service
      provider public keys and endpoint addresses, for example.

      To counter potential issues, the publisher may sign
      samlmetadata+xml typed objects. Any such signature should be
      verified by the recipient of the data - both as a valid
      signature, and as being the signature of the publisher.

      Additionally, various of the publication protocols, e.g.
      HTTP-over-TLS/SSL, offer means for ensuring the authenticity of
      the publishing party and for protecting the metadata in transit.
      [SAMLv2Meta] also defines prescriptive metadata caching
      directives, as well as guidance on handling HTTPS redirects,
      trust processing, server authentication, and related items.

      For a more detailed discussion of SAML v2.0 metadata and its
      security considerations, please see [SAMLv2Meta]. For a
      discussion of overall SAML v2.0 security considerations and
      specific security-related design features, please refer to the
      SAML v2.0 specifications listed in the below bibliography. The
      specifications containing security-specific information are
      explicitly listed.

Interoperability considerations:
      SAML v2.0 metadata explicitly supports identifying the protocols
      and versions supported by the identified entities. For example,
      an identity provider entity can be denoted as supporting SAML
      v2.0, SAML v1.1 [SAMLv1.1], Liberty ID-FF 1.2 [LAPFF], or even
      other protocols if they are unambiguously identifiable via URI
      [RFC2396]. This protocol support information is conveyed via the
      protocolSupportEnumeration attribute of metadata objects of the
      RoleDescriptorType.

Published specification:
      [SAMLv2Meta] explicitly specifies use of the
      application/samlmetadata+xml MIME media type.

Applications which use this media type:
      Potentially any application implementing SAML v2.0, as well as
      those applications implementing specifications based on SAML,
      e.g. those available from the Liberty Alliance [LAP].

Additional information:

      Magic number(s):
           In general, the same as for application/xml [RFC3023]. In
           particular, the XML root element of the returned object
           will be one of <md:EntityDescriptor>,
           <md:AffiliationDescriptor>, or <md:EntitiesDescriptor>.
           where "md" maps to the SAML v2.0 metadata namespace:
           urn:oasis:names:tc:SAML:2.0:metadata

      File extension(s): none
      Macintosh File Type Code(s): none

Person & email address to contact for further information:
      This registration is made on behalf of the OASIS Security
      Services Technical Committee (SSTC) Please refer to the SSTC
      website for current information on committee chairperson(s) and
      their contact addresses:
      http://www.oasis-open.org/committees/security/. Committee
      members should submit comments and potential errata to the
      [email-masked] list. Others should submit
      them by filling out the web form located at
      http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=s

      Additionally, the SAML developer community email distribution
      list, [email-masked], may be employed to discuss
      usage of the application/samlmetadata+xml MIME media type. The
      "saml-dev" mailing list is publicly archived here:
      http://lists.oasis-open.org/archives/saml-dev/. To post to the
      "saml-dev" mailing list, one must subscribe to it. To subscribe,
      send a message with the single word "subscribe" in the message
      body, to: [email-masked].

Intended usage: COMMON

Author/Change controller:
      The SAML specification sets are a work product of the OASIS
      Security Services Technical Committee (SSTC). OASIS and the SSTC
      have change control over the SAML specification sets.

Bibliography

      [LAP]          "Liberty Alliance Project". See
                     http://www.projectliberty.org/

      [LAPFF]        "Liberty Alliance Project: Federation Framework".
                     See http://www.projectliberty.org/resources/
                     specifications.php#box1

      [OASIS]        "Organization for the Advancement of Structured
                     Information Systems". See
                     http://www.oasis-open.org/

      [RFC2396]      T. Berners-Lee, R. Fielding, L. Masinter, Uniform
                     Resource Identifiers (URI): Generic Syntax. IETF
                     RFC 2396, August 1998. Available at
                     http://www.ietf.org/rfc/rfc2396.txt

      [RFC3023]      M. Murata, S. St.Laurent, D. Kohn, "XML Media Types",
                     IETF Request for Comments 3023, January 2001.
                     Available as
                     http://www.rfc-editor.org/rfc/rfc3023.txt

      [SAMLv1.1]     OASIS Security Services Technical Committee,
                     "Security Assertion Markup Language (SAML)
                     Version 1.1 Specification Set". OASIS Standard
                     200308, August 2003. Available as
                     http://www.oasis-open.org/committees/download.php
                     /3400/oasis-sstc-saml-1.1-pdf-xsd.zip

      [SAMLv2.0]     OASIS Security Services Technical Committee,
                     "Security Assertion Markup Language (SAML)
                     Version 2.0 Specification Set". WORK IN PROGRESS.
                     Available at
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Bind]   S. Cantor et al., "Bindings for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS
                     SSTC, August 2004. Document ID
                     sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS.
                     See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Core]   S. Cantor et al., "Assertions and Protocols for the
                     OASIS Security Assertion Markup Language (SAML)
                     V2.0". OASIS SSTC, August 2004. Document ID
                     sstc-saml-core-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Meta]   S. Cantor et al., Metadata for the OASIS Security
                     Assertion Markup Language (SAML) V2.0. OASIS
                     SSTC, August 2004. Document ID
                     sstc-saml-metadata-2.0-cd-01. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Prof]   S. Cantor et al., "Profiles for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS
                     SSTC, August 2004. Document ID
                     sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS.
                     See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Sec]    F. Hirsch et al., "Security and Privacy
                     Considerations for the OASIS Security Assertion
                     Markup Language (SAML) V2.0". OASIS SSTC, August
                     2004, WORK IN PROGRESS. Document ID
                     sstc-saml-sec-consider-2.0-cd-01. See
                     http://www.oasis-open.org/committees/security/

      [SSTC]         "OASIS Security Services Technical Committee". See
                     http://www.oasis-open.org/committees/security/

      [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler,
                     "Extensible Markup Language (XML) 1.0 (Second
                     Edition)", World Wide Web Consortium
                     Recommendation REC-xml, October 2000, Available
                     as http://www.w3.org/TR/REC-xml

---
end

From: Jeff.Hodges at Sun.COM (Jeff Hodges)
Date: Tue Jan  3 16:22:46 2006
Subject: DRAFT Registration of MIME media type application/samlmetadata+xml
Message-ID: <[email-masked]>

comments appreciated...

thanks,
JeffH
-----

<NOTE:
Registration of MIME media type application/samlmetadata+xml
sstc-saml-2.0-application-samlmetadata-registration-00
Jeff Hodges <[email-masked]>
23-Aug-2004

This document is intended to be included in
sstc-saml-metadata-2.0-cd-02 (ie the next time [SAMLv2Meta] is
rev'd), as an appendix.

Please see http://www.w3.org/2002/06/registering-mediatype.html for
an overview of the intricities involved when a non-IETF organization
registers a MIME media type in the "standards tree" (aka "IETF
tree").

The below registration material is intended to satisfy the
requirements stated in draft-freed-media-type-reg-01.txt (which
superseded draft-freed-mime-p4-04.txt).

This "NOTE" is intended to be removed upon copying this document's
content into [SAMLv2Meta].

Acknowledgments: Thanks to Ned Freed and Larry Masinter for their
comments on a draft of a related registration. The security
considerations section leverages that of
http://www.iana.org/assignments/media-types/application/vnd.paos+xml,
by John Kemp.
 >

To: [email-masked]
Subject: Registration of MIME media type application/samlmetadata+xml

Introduction
      This document defines a MIME media type --
      application/samlmetadata+xml -- for use with the XML
      serialization of Security Assertion Markup Language metadata.

      SAML is a work product of the OASIS Security Services Technical
      Committee [SSTC]. The SAML specifications define XML-based
      constructs with which one may make, and convey, security
      assertions. Using SAML, one can assert that an authentication
      event pertaining to some subject has occurred and convey said
      assertion to a relying party, for example.

      SAML profiles require agreements between system entities
      regarding identifiers, binding support, endpoints, certificates,
      keys, and so forth. Such information is treated as metadata by
      SAML v2.0. [SAMLv2Meta] specifies this metadata, as well as
      specifying metadata publication and resolution mechanisms. If
      the publishing protocol permits MIME-based identification of
      content types, then use of the application/samlmetadata+xml MIME
      media type is required.

MIME media type name: application

MIME subtype name: samlmetadata+xml

Required parameters: none

Optional parameters: charset
      Same as charset parameter of application/xml [RFC3023].

Encoding considerations:
      Same as for application/xml [RFC3023].

Security considerations:
      Per their specification, samlmetadata+xml typed objects do not
      contain executable content. However, these objects are XML-based
      [XML], and thus they have all of the general security
      considerations presented in section 10 of [RFC3023].

      SAML metadata [SAMLv2Meta] contains information whose integrity
      and authenticity is important ? identity provider and service
      provider public keys and endpoint addresses, for example.

      To counter potential issues, the publisher may sign
      samlmetadata+xml typed objects. Any such signature should be
      verified by the recipient of the data - both as a valid
      signature, and as being the signature of the publisher.

      Additionally, various of the publication protocols, e.g.
      HTTP-over-TLS/SSL, offer means for ensuring the authenticity of
      the publishing party and for protecting the metadata in transit.
      [SAMLv2Meta] also defines prescriptive metadata caching
      directives, as well as guidance on handling HTTPS redirects,
      trust processing, server authentication, and related items.

      For a more detailed discussion of SAML v2.0 metadata and its
      security considerations, please see [SAMLv2Meta]. For a
      discussion of overall SAML v2.0 security considerations and
      specific security-related design features, please refer to the
      SAML v2.0 specifications listed in the below bibliography. The
      specifications containing security-specific information are
      explicitly listed.

Interoperability considerations:
      SAML v2.0 metadata explicitly supports identifying the protocols
      and versions supported by the identified entities. For example,
      an identity provider entity can be denoted as supporting SAML
      v2.0, SAML v1.1 [SAMLv1.1], Liberty ID-FF 1.2 [LAPFF], or even
      other protocols if they are unambiguously identifiable via URI
      [RFC2396]. This protocol support information is conveyed via the
      protocolSupportEnumeration attribute of metadata objects of the
      RoleDescriptorType.

Published specification:
      [SAMLv2Meta] explicitly specifies use of the
      application/samlmetadata+xml MIME media type.

Applications which use this media type:
      Potentially any application implementing SAML v2.0, as well as
      those applications implementing specifications based on SAML,
      e.g. those available from the Liberty Alliance [LAP].

Additional information:

      Magic number(s):
           In general, the same as for application/xml [RFC3023]. In
           particular, the XML root element of the returned object
           will be one of <md:EntityDescriptor>,
           <md:AffiliationDescriptor>, or <md:EntitiesDescriptor>.
           where "md" maps to the SAML v2.0 metadata namespace:
           urn:oasis:names:tc:SAML:2.0:metadata

      File extension(s): none
      Macintosh File Type Code(s): none

Person & email address to contact for further information:
      This registration is made on behalf of the OASIS Security
      Services Technical Committee (SSTC) Please refer to the SSTC
      website for current information on committee chairperson(s) and
      their contact addresses:
      http://www.oasis-open.org/committees/security/. Committee
      members should submit comments and potential errata to the
      [email-masked] list. Others should submit
      them by filling out the web form located at
      http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=s

      Additionally, the SAML developer community email distribution
      list, [email-masked], may be employed to discuss
      usage of the application/samlmetadata+xml MIME media type. The
      "saml-dev" mailing list is publicly archived here:
      http://lists.oasis-open.org/archives/saml-dev/. To post to the
      "saml-dev" mailing list, one must subscribe to it. To subscribe,
      send a message with the single word "subscribe" in the message
      body, to: [email-masked].

Intended usage: COMMON

Author/Change controller:
      The SAML specification sets are a work product of the OASIS
      Security Services Technical Committee (SSTC). OASIS and the SSTC
      have change control over the SAML specification sets.

Bibliography

      [LAP]          "Liberty Alliance Project". See
                     http://www.projectliberty.org/

      [LAPFF]        "Liberty Alliance Project: Federation Framework".
                     See http://www.projectliberty.org/resources/
                     specifications.php#box1

      [OASIS]        "Organization for the Advancement of Structured
                     Information Systems". See
                     http://www.oasis-open.org/

      [RFC2396]      T. Berners-Lee, R. Fielding, L. Masinter, Uniform
                     Resource Identifiers (URI): Generic Syntax. IETF
                     RFC 2396, August 1998. Available at
                     http://www.ietf.org/rfc/rfc2396.txt

      [RFC3023]      M. Murata, S. St.Laurent, D. Kohn, "XML Media Types",
                     IETF Request for Comments 3023, January 2001.
                     Available as
                     http://www.rfc-editor.org/rfc/rfc3023.txt

      [SAMLv1.1]     OASIS Security Services Technical Committee,
                     "Security Assertion Markup Language (SAML)
                     Version 1.1 Specification Set". OASIS Standard
                     200308, August 2003. Available as
                     http://www.oasis-open.org/committees/download.php
                     /3400/oasis-sstc-saml-1.1-pdf-xsd.zip

      [SAMLv2.0]     OASIS Security Services Technical Committee,
                     "Security Assertion Markup Language (SAML)
                     Version 2.0 Specification Set". WORK IN PROGRESS.
                     Available at
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Bind]   S. Cantor et al., "Bindings for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS
                     SSTC, August 2004. Document ID
                     sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS.
                     See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Core]   S. Cantor et al., "Assertions and Protocols for the
                     OASIS Security Assertion Markup Language (SAML)
                     V2.0". OASIS SSTC, August 2004. Document ID
                     sstc-saml-core-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Meta]   S. Cantor et al., Metadata for the OASIS Security
                     Assertion Markup Language (SAML) V2.0. OASIS
                     SSTC, August 2004. Document ID
                     sstc-saml-metadata-2.0-cd-01. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Prof]   S. Cantor et al., "Profiles for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS
                     SSTC, August 2004. Document ID
                     sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS.
                     See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Sec]    F. Hirsch et al., "Security and Privacy
                     Considerations for the OASIS Security Assertion
                     Markup Language (SAML) V2.0". OASIS SSTC, August
                     2004, WORK IN PROGRESS. Document ID
                     sstc-saml-sec-consider-2.0-cd-01. See
                     http://www.oasis-open.org/committees/security/

      [SSTC]         "OASIS Security Services Technical Committee". See
                     http://www.oasis-open.org/committees/security/

      [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler,
                     "Extensible Markup Language (XML) 1.0 (Second
                     Edition)", World Wide Web Consortium
                     Recommendation REC-xml, October 2000, Available
                     as http://www.w3.org/TR/REC-xml

---
end

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Jan  3 16:22:46 2006
Subject: DRAFT Registration of MIME media type  application/samlassertion+xml
In-Reply-To: Jeff Hodges <[email-masked]> 's message of  Sat, 21 Aug 2004 12:32:55 -0700
Message-ID: <[email-masked]>

oops, fixed a small-but-important bug: corrected MIME subtype name.

JeffH
-----

<NOTE:
Registration of MIME media type application/samlassertion+xml
sstc-saml-2.0-application-samlassertion-registration-00
Jeff Hodges <[email-masked]>
21-Aug-2004

This document supersedes draft-hodges-saml-mediatype-02.txt. It
is intended to be included in sstc-saml-bindings-2.0-cd-02 (ie the next
time [SAMLv2Bind] is rev'd) as an appendix.

For an overview of the intricities involved when a non-IETF organization
registers a MIME media type in the "standards tree" (aka "IETF tree"),
please see http://www.w3.org/2002/06/registering-mediatype.html.

The below registration material is intended to satisfy the requirements
stated in draft-freed-media-type-reg-01.txt (which superseded
draft-freed-mime-p4-04.txt).

This "NOTE" is intended to be removed upon copying this document's
content into [SAMLv2Bind].

Acknowledgments: Thanks to Ned Freed and Larry Masinter for their
comments on a prior draft of this registration. The security
considerations section leverages that of
http://www.iana.org/assignments/media-types/application/vnd.paos+xml, by
John Kemp.
 >

To: [email-masked]
Subject: Registration of MIME media type application/samlassertion+xml

Introduction
      This document defines a MIME media type --
      application/samlassertion+xml -- for use with the XML serialization
      of SAML (Security Assertion Markup Language) assertions.

      The SAML specification sets -- [SAMLv1.0], [SAMLv1.1], [SAMLv2.0] --
      are work products of the OASIS Security Services Technical Committee
      [SSTC]. The SAML specifications define XML-based constructs with
      which one may make, and convey, security assertions. Using SAML, one
      can assert that an authentication event pertaining to some subject
      has occured and convey said assertion to a relying party, for
      example.

      SAML assertions, which are explicitly versioned, are defined by
      [SAMLv1Core], [SAMLv11Core], and [SAMLv2Core].

MIME media type name: application

MIME subtype name: samlassertion+xml

Required parameters: none

Optional parameters: charset
      Same as charset parameter of application/xml [RFC3023].

Encoding considerations:
      Same as for application/xml [RFC3023].

Security considerations:
      Per their specification, samlassertion+xml typed objects do not
      contain executable content. However, SAML assertions are XML-based
      objects [XML]. As such, they have all of the general security
      considerations presented in section 10 of [RFC3023], as well as
      additional ones, since they are explicit security objects. For
      example, samlassertion+xml typed objects will often contain data
      that may identify or pertain to a natural person, and may be used as
      a basis for sessions and access control decisions.

      To counter potential issues, samlassertion+xml typed objects contain
      data that should be signed appropriately by the sender. Any such
      signature must be verified by the recipient of the data - both as a
      valid signature, and as being the signature of the sender. Issuers
      of samlassertion+xml objects containing SAMLv2 assertions may also
      encrypt all, or portions of, the assertions [SAMLv2Core].

      In addition, SAML profiles and protocol bindings specify use of
      secure channels as appropriate.

      [SAMLv2.0] incorporates various privacy-protection techniques in its
      design. For example: opaque handles, specific to interactions
      between specific system entities, are assigned to subjects. The
      handles are mappable to wider-context identifiers (e.g. email
      addresses, account identifiers, etc) by only the specific parties.

      For a more detailed discussion of SAML security considerations and
      specific security-related design techniques, please refer to the
      SAML specifications listed in the below bibliography. The
      specifications containing security-specific information have been
      explicitly listed for each version of SAML.

Interoperability considerations:
      SAML assertions are explicitly versioned. Relying parties should
      ensure that they observe assertion version information and behave
      accordingly. See "Chapter 4 SAML Versioning" in [SAMLv1Core],
      [SAMLv11Core], or [SAMLv2Core], as appropriate.

Published specification:
      [SAMLv2Bind] explicitly specifies use of the
      application/samlassertion+xml MIME media type. However, it is
      conceivable that non-SAMLv2 assertions (i.e. SAMLv1 and/or SAMLv1.1)
      might in practice be conveyed using SAMLv2 bindings.

Applications which use this media type:
      Potentially any application implementing SAML, as well as those
      applications implementing specifications based on SAML, e.g. those
      available from the Liberty Alliance [LAP].

Additional information:

      Magic number(s):
           In general, the same as for application/xml [RFC3023]. In
           particular, the XML root element of the returned object will be
           <saml:Assertion>, where "saml" maps to a version-specific SAML
           assertion namespace, as defined by the appropriate SAML "core"
           specification (see bibliography). In the case of SAMLv2.0, the
           root element of the returned object may be either
           <saml:Assertion> or <saml:EncryptedAssertion>, where "saml"
           maps to the SAMLv2.0 assertion namespace:
           urn:oasis:names:tc:SAML:2.0:assertion

      File extension(s): none
      Macintosh File Type Code(s): none

Person & email address to contact for further information:
      This registration is made on behalf of the OASIS Security Services
      Technical Committee (SSTC) Please refer to the SSTC website for
      current information on committee chairperson(s) and their contact
      addresses: http://www.oasis-open.org/committees/security/. Committee
      members should submit comments and potential errata to the
      [email-masked] list. Others should submit
      them by filling out the web form located at
      http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=secur

      Additionally, the SAML developer community email distribution list,
      [email-masked], may be employed to discuss usage of
      the application/samlassertion+xml MIME media type. The "saml-dev"
      mailing list is publicly archived here:
      http://lists.oasis-open.org/archives/saml-dev/. To post to the
      "saml-dev" mailing list, one must subscribe to it. To subscribe,
      send a message with the single word "subscribe" in the message body,
      to: [email-masked].

Intended usage: COMMON

Author/Change controller:
      The SAML specification sets are a work product of the OASIS Security
      Services Technical Committee (SSTC). OASIS and the SSTC have change
      control over the SAML specification sets.

Bibliography

      [LAP]          "Liberty Alliance Project". See
                     http://www.projectliberty.org/

      [OASIS]        "Organization for the Advancement of Structured
                     Information Systems". See http://www.oasis-open.org/

      [RFC3023]      M. Murata, S. St.Laurent, D. Kohn, "XML Media Types",
                     IETF Request for Comments 3023, January 2001. Available
                     as http://www.rfc-editor.org/rfc/rfc3023.txt

      [SAMLv1.0]     OASIS Security Services Technical Committee, "Security
                     Assertion Markup Language (SAML) Version 1.0
                     Specification Set". OASIS Standard 200205, November
                     2002. Available as
                     http://www.oasis-open.org/committees/download.php/2290/
                     oasis-sstc-saml-1.0.zip

      [SAMLv1Bind]   Prateek Mishra et al., "Bindings and Profiles for the
                     OASIS Security Assertion Markup Language (SAML)",
                     OASIS, November 2002. Document ID
                     oasis-sstc-saml-bindings-1.0. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv1Core]   Phillip Hallam-Baker et al., "Assertions and Protocol
                     for the OASIS Security Assertion Markup Language
                     (SAML)", OASIS, November 2002. Document ID
                     oasis-sstc-saml-core-1.0. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv1Sec]    Chris McLaren et al., "Security Considerations for the
                     OASIS Security Assertion Markup Language (SAML)",
                     OASIS, November 2002. Document ID
                     oasis-sstc-saml-sec-consider-1.0. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv1.1]     OASIS Security Services Technical Committee, "Security
                     Assertion Markup Language (SAML) Version 1.1
                     Specification Set". OASIS Standard 200308, August
                     2003. Available as
                     http://www.oasis-open.org/committees/download.php/3400/
                     oasis-sstc-saml-1.1-pdf-xsd.zip

      [SAMLv11Bind]  E. Maler et al. "Bindings and Profiles for the OASIS
                     Security Assertion Markup Language (SAML)". OASIS,
                     September 2003. Document ID
                     oasis-sstc-saml-bindings-1.1.
                     http://www.oasis-open.org/committees/security/

      [SAMLv11Core]  E. Maler et al. "Assertions and Protocol for the OASIS
                     Security Assertion Markup Language (SAML)". OASIS,
                     September 2003. Document ID oasis-sstc-saml-core-1.1.
                     http://www.oasis-open.org/committees/security/

      [SAMLv11Sec]   E. Maler et al. "Security Considerations for the OASIS
                     Security Assertion Markup Language (SAML)". OASIS,
                     September 2003. Document ID
                     oasis-sstc-saml-sec-consider-1.1.
                     http://www.oasis-open.org/committees/security/

      [SAMLv2.0]     OASIS Security Services Technical Committee, "Security
                     Assertion Markup Language (SAML) Version 2.0
                     Specification Set". WORK IN PROGRESS. Available at
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Bind]   S. Cantor et al., "Bindings for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS SSTC,
                     August 2004. Document ID
                     sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Core]   S. Cantor et al., "Assertions and Protocols for the
                     OASIS Security Assertion Markup Language (SAML)
                     V2.0". OASIS SSTC, August 2004. Document ID
                     sstc-saml-core-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Prof]   S. Cantor et al., "Profiles for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS SSTC,
                     August 2004. Document ID
                     sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Sec]    F. Hirsch et al., "Security and Privacy Considerations
                     for the OASIS Security Assertion Markup Language
                     (SAML) V2.0". OASIS SSTC, August 2004, WORK IN
                     PROGRESS. Document ID
                     sstc-saml-sec-consider-2.0-cd-01. See
                     http://www.oasis-open.org/committees/security/

      [SSTC]        "OASIS Security Services Technical Committee". See
                     http://www.oasis-open.org/committees/security/

      [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler,
                     "Extensible Markup Language (XML) 1.0 (Second
                     Edition)", World Wide Web Consortium Recommendation
                     REC-xml, October 2000, Available as
                     http://www.w3.org/TR/REC-xml

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Mon Aug 23 14:03:51 2004
Subject: Pre review of 3GPP MIME type for RTP payload format
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Larry,

Okay I will try to make a more complete explanation of how things fit to 
together.

RTP is protocol that can be used by different applications. However most 
of the applications, like VoIP or Streaming do use SDP (RFC 2327) to 
configure RTP and the used media codecs and payload formats. An example 
of a media block that configures one RTP session is:

    m=video 49170 RTP/AVPF 96 97
    c=IN IP4 192.0.2.0
    a=rtpmap:96 MP4V-ES/90000
    a=rtcp-fb:96 nack
    a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
    0A21F
    a=rtpmap:97 rtx/90000
    a=fmtp:97 apt=96;rtx-time=3000

Where the m= lines first indicates the media type (video), and the 
a=rtpmap indicates the subtype which represents the actual RTP payload 
formats used in this session. The payload type numbers (96 and 97) are 
used in RTP header to identify the actual payload of a received RTP 
packet. In this case the session support the usage of MPEG-4 video using 
the RTP payload format for elementary streams defined in RFC 3016 
(payload type 96), and the RTP payload format for retransmission 
(payload type 97) which is defined in 
(draft-ietf-avt-rtp-retransmission-10). The mapping of media type and 
subtype to SDP is defined in RFC 3555.

If you would like to have also audio to this session, then you would 
need to have an SDP with another media block which defines the audio 
part. Through the actual definition of a new media block, one defines 
that a completely separated RTP session shall be used. For example the 
following:

     m=audio 49120 RTP/AVP 98
     a=rtpmap:98 AMR-WB/16000
     a=fmtp:98 octet-align=1

Which tells the receiver that it needs the audio codec AMR-WB and the 
RTP payload format specified in RFC 3267, by referencing the registered 
MIME type (audio/AMR-WB). In addition as this payload format has more 
then one configuration the a=fmtp line does tell it to use the 
octet-aligned mode of packetization.

As I previously indicated, there are good reasons why audio and the 
video streams shall be sent over different RTP sessions. And SDP is 
tailored to provide this by specifying the media type at a media block 
level, rather than at each individual payload type.

So it is actually the limited possibility to express that an RTP session 
should contain for example audio/amr-wb and application/rtp.enc.aes128 
that is the blocking factor. But this limitation is good, as it ensure 
that people do not do bad multiplexing decisions. We must also consider 
the huge deployed base of SDP parsing applications that would fold over 
in the face of change to allow different media types in the same media 
block.

Direct comments below.

Larry Masinter wrote:

> Part of the problem is that RFC 3555 (MIME Type Registration
> of RTP Payload Types) isn't marked as updating RFC 2048, even though
> it seems to be intended to.
> 

That, is probably true. And this will be fixed in the update process to 
resolve this whole thing. As I understand it, Ned Freed will provide an 
update version of the MIME registration rules that introduces the domain 
of applicability concept there. To my knowledge a first draft is 
available of that. When that has been resolved we will update RFC 3555 
to ensure that it is consistent with the new rules.

> 
>>[mw]
>>The fact is that RTP and its signalling do require the 
>>registration in the applicable. For RTP there is a clear 
>>explanation in RFC 3550 why it is harmful to mix different 
>>media types in the same RTP session. Due to this reason also 
>>the signalling in SDP does not allow the mixing of multiple 
>>media types in the same RTP session. So due to the above 
>>restrictions one can not register an single 
>>application/rtp.enc.aes128 to secure all the different media 
>>top levels. 
>>[\mw]
> 
> 
> I looked at RFC 3550, and can find no mention
> of MIME or any references to the media type registry,
> so I don't understand where this 'clear explanation'
> might be. There is a definition of a 'RTP media type':
> 
>    RTP media type: An RTP media type is the collection of payload
>       types which can be carried within a single RTP session.  The RTP
>       Profile assigns RTP media types to RTP payload types.
> 
> but I don't see what this has to do with MIME media types.
> Can you be more explicit about where this is clearly explained?
> 

The usage of MIME to label RTP payload format and its associated codec 
is defined by RFC 3555. However I don't think it is properly explained 
if it is not in RFC 3555.

> It's hard to trace from 3555 and 3550 to the requirement that
> different kinds of data need different top-level text/ audio/
> video/ types.
> 

Yes, as explained above, this is a combination of RTP and SDP behavior.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
>From [email-masked]  Mon Aug 23 15:25:01 2004
From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Mon Aug 23 15:25:10 2004
Subject: DRAFT Registration of MIME media type 
 application/samlassertion+xml
In-Reply-To: Jeff Hodges <[email-masked]> 's message of 
	Sat, 21 Aug 2004 12:32:55 -0700
Message-ID: <[email-masked]>

oops, fixed a small-but-important bug: corrected MIME subtype name.

JeffH
-----

<NOTE:
Registration of MIME media type application/samlassertion+xml
sstc-saml-2.0-application-samlassertion-registration-00
Jeff Hodges <[email-masked]>
21-Aug-2004

This document supersedes draft-hodges-saml-mediatype-02.txt. It
is intended to be included in sstc-saml-bindings-2.0-cd-02 (ie the next
time [SAMLv2Bind] is rev'd) as an appendix.

For an overview of the intricities involved when a non-IETF organization
registers a MIME media type in the "standards tree" (aka "IETF tree"),
please see http://www.w3.org/2002/06/registering-mediatype.html.

The below registration material is intended to satisfy the requirements
stated in draft-freed-media-type-reg-01.txt (which superseded
draft-freed-mime-p4-04.txt).

This "NOTE" is intended to be removed upon copying this document's
content into [SAMLv2Bind].

Acknowledgments: Thanks to Ned Freed and Larry Masinter for their
comments on a prior draft of this registration. The security
considerations section leverages that of
http://www.iana.org/assignments/media-types/application/vnd.paos+xml, by
John Kemp.
 >

To: [email-masked]
Subject: Registration of MIME media type application/samlassertion+xml

Introduction
      This document defines a MIME media type --
      application/samlassertion+xml -- for use with the XML serialization
      of SAML (Security Assertion Markup Language) assertions.

      The SAML specification sets -- [SAMLv1.0], [SAMLv1.1], [SAMLv2.0] --
      are work products of the OASIS Security Services Technical Committee
      [SSTC]. The SAML specifications define XML-based constructs with
      which one may make, and convey, security assertions. Using SAML, one
      can assert that an authentication event pertaining to some subject
      has occured and convey said assertion to a relying party, for
      example.

      SAML assertions, which are explicitly versioned, are defined by
      [SAMLv1Core], [SAMLv11Core], and [SAMLv2Core].

MIME media type name: application

MIME subtype name: samlassertion+xml

Required parameters: none

Optional parameters: charset
      Same as charset parameter of application/xml [RFC3023].

Encoding considerations:
      Same as for application/xml [RFC3023].

Security considerations:
      Per their specification, samlassertion+xml typed objects do not
      contain executable content. However, SAML assertions are XML-based
      objects [XML]. As such, they have all of the general security
      considerations presented in section 10 of [RFC3023], as well as
      additional ones, since they are explicit security objects. For
      example, samlassertion+xml typed objects will often contain data
      that may identify or pertain to a natural person, and may be used as
      a basis for sessions and access control decisions.

      To counter potential issues, samlassertion+xml typed objects contain
      data that should be signed appropriately by the sender. Any such
      signature must be verified by the recipient of the data - both as a
      valid signature, and as being the signature of the sender. Issuers
      of samlassertion+xml objects containing SAMLv2 assertions may also
      encrypt all, or portions of, the assertions [SAMLv2Core].

      In addition, SAML profiles and protocol bindings specify use of
      secure channels as appropriate.

      [SAMLv2.0] incorporates various privacy-protection techniques in its
      design. For example: opaque handles, specific to interactions
      between specific system entities, are assigned to subjects. The
      handles are mappable to wider-context identifiers (e.g. email
      addresses, account identifiers, etc) by only the specific parties.

      For a more detailed discussion of SAML security considerations and
      specific security-related design techniques, please refer to the
      SAML specifications listed in the below bibliography. The
      specifications containing security-specific information have been
      explicitly listed for each version of SAML.

Interoperability considerations:
      SAML assertions are explicitly versioned. Relying parties should
      ensure that they observe assertion version information and behave
      accordingly. See "Chapter 4 SAML Versioning" in [SAMLv1Core],
      [SAMLv11Core], or [SAMLv2Core], as appropriate.

Published specification:
      [SAMLv2Bind] explicitly specifies use of the
      application/samlassertion+xml MIME media type. However, it is
      conceivable that non-SAMLv2 assertions (i.e. SAMLv1 and/or SAMLv1.1)
      might in practice be conveyed using SAMLv2 bindings.

Applications which use this media type:
      Potentially any application implementing SAML, as well as those
      applications implementing specifications based on SAML, e.g. those
      available from the Liberty Alliance [LAP].

Additional information:

      Magic number(s):
           In general, the same as for application/xml [RFC3023]. In
           particular, the XML root element of the returned object will be
           <saml:Assertion>, where "saml" maps to a version-specific SAML
           assertion namespace, as defined by the appropriate SAML "core"
           specification (see bibliography). In the case of SAMLv2.0, the
           root element of the returned object may be either
           <saml:Assertion> or <saml:EncryptedAssertion>, where "saml"
           maps to the SAMLv2.0 assertion namespace:
           urn:oasis:names:tc:SAML:2.0:assertion

      File extension(s): none
      Macintosh File Type Code(s): none

Person & email address to contact for further information:
      This registration is made on behalf of the OASIS Security Services
      Technical Committee (SSTC) Please refer to the SSTC website for
      current information on committee chairperson(s) and their contact
      addresses: http://www.oasis-open.org/committees/security/. Committee
      members should submit comments and potential errata to the
      [email-masked] list. Others should submit
      them by filling out the web form located at
      http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=secur

      Additionally, the SAML developer community email distribution list,
      [email-masked], may be employed to discuss usage of
      the application/samlassertion+xml MIME media type. The "saml-dev"
      mailing list is publicly archived here:
      http://lists.oasis-open.org/archives/saml-dev/. To post to the
      "saml-dev" mailing list, one must subscribe to it. To subscribe,
      send a message with the single word "subscribe" in the message body,
      to: [email-masked].

Intended usage: COMMON

Author/Change controller:
      The SAML specification sets are a work product of the OASIS Security
      Services Technical Committee (SSTC). OASIS and the SSTC have change
      control over the SAML specification sets.

Bibliography

      [LAP]          "Liberty Alliance Project". See
                     http://www.projectliberty.org/

      [OASIS]        "Organization for the Advancement of Structured
                     Information Systems". See http://www.oasis-open.org/

      [RFC3023]      M. Murata, S. St.Laurent, D. Kohn, "XML Media Types",
                     IETF Request for Comments 3023, January 2001. Available
                     as http://www.rfc-editor.org/rfc/rfc3023.txt

      [SAMLv1.0]     OASIS Security Services Technical Committee, "Security
                     Assertion Markup Language (SAML) Version 1.0
                     Specification Set". OASIS Standard 200205, November
                     2002. Available as
                     http://www.oasis-open.org/committees/download.php/2290/
                     oasis-sstc-saml-1.0.zip

      [SAMLv1Bind]   Prateek Mishra et al., "Bindings and Profiles for the
                     OASIS Security Assertion Markup Language (SAML)",
                     OASIS, November 2002. Document ID
                     oasis-sstc-saml-bindings-1.0. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv1Core]   Phillip Hallam-Baker et al., "Assertions and Protocol
                     for the OASIS Security Assertion Markup Language
                     (SAML)", OASIS, November 2002. Document ID
                     oasis-sstc-saml-core-1.0. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv1Sec]    Chris McLaren et al., "Security Considerations for the
                     OASIS Security Assertion Markup Language (SAML)",
                     OASIS, November 2002. Document ID
                     oasis-sstc-saml-sec-consider-1.0. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv1.1]     OASIS Security Services Technical Committee, "Security
                     Assertion Markup Language (SAML) Version 1.1
                     Specification Set". OASIS Standard 200308, August
                     2003. Available as
                     http://www.oasis-open.org/committees/download.php/3400/
                     oasis-sstc-saml-1.1-pdf-xsd.zip

      [SAMLv11Bind]  E. Maler et al. "Bindings and Profiles for the OASIS
                     Security Assertion Markup Language (SAML)". OASIS,
                     September 2003. Document ID
                     oasis-sstc-saml-bindings-1.1.
                     http://www.oasis-open.org/committees/security/

      [SAMLv11Core]  E. Maler et al. "Assertions and Protocol for the OASIS
                     Security Assertion Markup Language (SAML)". OASIS,
                     September 2003. Document ID oasis-sstc-saml-core-1.1.
                     http://www.oasis-open.org/committees/security/

      [SAMLv11Sec]   E. Maler et al. "Security Considerations for the OASIS
                     Security Assertion Markup Language (SAML)". OASIS,
                     September 2003. Document ID
                     oasis-sstc-saml-sec-consider-1.1.
                     http://www.oasis-open.org/committees/security/

      [SAMLv2.0]     OASIS Security Services Technical Committee, "Security
                     Assertion Markup Language (SAML) Version 2.0
                     Specification Set". WORK IN PROGRESS. Available at
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Bind]   S. Cantor et al., "Bindings for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS SSTC,
                     August 2004. Document ID
                     sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Core]   S. Cantor et al., "Assertions and Protocols for the
                     OASIS Security Assertion Markup Language (SAML)
                     V2.0". OASIS SSTC, August 2004. Document ID
                     sstc-saml-core-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Prof]   S. Cantor et al., "Profiles for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS SSTC,
                     August 2004. Document ID
                     sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Sec]    F. Hirsch et al., "Security and Privacy Considerations
                     for the OASIS Security Assertion Markup Language
                     (SAML) V2.0". OASIS SSTC, August 2004, WORK IN
                     PROGRESS. Document ID
                     sstc-saml-sec-consider-2.0-cd-01. See
                     http://www.oasis-open.org/committees/security/

      [SSTC]        "OASIS Security Services Technical Committee". See
                     http://www.oasis-open.org/committees/security/

      [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler,
                     "Extensible Markup Language (XML) 1.0 (Second
                     Edition)", World Wide Web Consortium Recommendation
                     REC-xml, October 2000, Available as
                     http://www.w3.org/TR/REC-xml

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Tue Jan  3 16:22:46 2006
Subject: Pre review of 3GPP MIME type for RTP payload format
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Larry,

Okay I will try to make a more complete explanation of how things fit to 
together.

RTP is protocol that can be used by different applications. However most 
of the applications, like VoIP or Streaming do use SDP (RFC 2327) to 
configure RTP and the used media codecs and payload formats. An example 
of a media block that configures one RTP session is:

    m=video 49170 RTP/AVPF 96 97
    c=IN IP4 192.0.2.0
    a=rtpmap:96 MP4V-ES/90000
    a=rtcp-fb:96 nack
    a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
    0A21F
    a=rtpmap:97 rtx/90000
    a=fmtp:97 apt=96;rtx-time=3000

Where the m= lines first indicates the media type (video), and the 
a=rtpmap indicates the subtype which represents the actual RTP payload 
formats used in this session. The payload type numbers (96 and 97) are 
used in RTP header to identify the actual payload of a received RTP 
packet. In this case the session support the usage of MPEG-4 video using 
the RTP payload format for elementary streams defined in RFC 3016 
(payload type 96), and the RTP payload format for retransmission 
(payload type 97) which is defined in 
(draft-ietf-avt-rtp-retransmission-10). The mapping of media type and 
subtype to SDP is defined in RFC 3555.

If you would like to have also audio to this session, then you would 
need to have an SDP with another media block which defines the audio 
part. Through the actual definition of a new media block, one defines 
that a completely separated RTP session shall be used. For example the 
following:

     m=audio 49120 RTP/AVP 98
     a=rtpmap:98 AMR-WB/16000
     a=fmtp:98 octet-align=1

Which tells the receiver that it needs the audio codec AMR-WB and the 
RTP payload format specified in RFC 3267, by referencing the registered 
MIME type (audio/AMR-WB). In addition as this payload format has more 
then one configuration the a=fmtp line does tell it to use the 
octet-aligned mode of packetization.

As I previously indicated, there are good reasons why audio and the 
video streams shall be sent over different RTP sessions. And SDP is 
tailored to provide this by specifying the media type at a media block 
level, rather than at each individual payload type.

So it is actually the limited possibility to express that an RTP session 
should contain for example audio/amr-wb and application/rtp.enc.aes128 
that is the blocking factor. But this limitation is good, as it ensure 
that people do not do bad multiplexing decisions. We must also consider 
the huge deployed base of SDP parsing applications that would fold over 
in the face of change to allow different media types in the same media 
block.

Direct comments below.

Larry Masinter wrote:

> Part of the problem is that RFC 3555 (MIME Type Registration
> of RTP Payload Types) isn't marked as updating RFC 2048, even though
> it seems to be intended to.
> 

That, is probably true. And this will be fixed in the update process to 
resolve this whole thing. As I understand it, Ned Freed will provide an 
update version of the MIME registration rules that introduces the domain 
of applicability concept there. To my knowledge a first draft is 
available of that. When that has been resolved we will update RFC 3555 
to ensure that it is consistent with the new rules.

> 
>>[mw]
>>The fact is that RTP and its signalling do require the 
>>registration in the applicable. For RTP there is a clear 
>>explanation in RFC 3550 why it is harmful to mix different 
>>media types in the same RTP session. Due to this reason also 
>>the signalling in SDP does not allow the mixing of multiple 
>>media types in the same RTP session. So due to the above 
>>restrictions one can not register an single 
>>application/rtp.enc.aes128 to secure all the different media 
>>top levels. 
>>[\mw]
> 
> 
> I looked at RFC 3550, and can find no mention
> of MIME or any references to the media type registry,
> so I don't understand where this 'clear explanation'
> might be. There is a definition of a 'RTP media type':
> 
>    RTP media type: An RTP media type is the collection of payload
>       types which can be carried within a single RTP session.  The RTP
>       Profile assigns RTP media types to RTP payload types.
> 
> but I don't see what this has to do with MIME media types.
> Can you be more explicit about where this is clearly explained?
> 

The usage of MIME to label RTP payload format and its associated codec 
is defined by RFC 3555. However I don't think it is properly explained 
if it is not in RFC 3555.

> It's hard to trace from 3555 and 3550 to the requirement that
> different kinds of data need different top-level text/ audio/
> video/ types.
> 

Yes, as explained above, this is a combination of RTP and SDP behavior.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

From: Jeff.Hodges at Sun.COM (Jeff Hodges)
Date: Sat Aug 21 21:34:09 2004
Subject: DRAFT Registration of MIME media type application/samlassertion+xml
Message-ID: <[email-masked]>

comments appreciated...

thanks,
JeffH
-----

<NOTE:
Registration of MIME media type application/samlassertion+xml
sstc-saml-2.0-application-samlassertion-registration-00
Jeff Hodges <[email-masked]>
21-Aug-2004

This document supersedes draft-hodges-saml-mediatype-02.txt. It
is intended to be included in sstc-saml-bindings-2.0-cd-02 (ie the next
time [SAMLv2Bind] is rev'd) as an appendix.

For an overview of the intricities involved when a non-IETF organization
registers a MIME media type in the "standards tree" (aka "IETF tree"),
please see http://www.w3.org/2002/06/registering-mediatype.html.

The below registration material is intended to satisfy the requirements
stated in draft-freed-media-type-reg-01.txt (which superseded
draft-freed-mime-p4-04.txt).

This "NOTE" is intended to be removed upon copying this document's
content into [SAMLv2Bind].

Acknowledgments: Thanks to Ned Freed and Larry Masinter for their
comments on a prior draft of this registration. The security
considerations section leverages that of
http://www.iana.org/assignments/media-types/application/vnd.paos+xml, by
John Kemp.
 >

To: [email-masked]
Subject: Registration of MIME media type application/samlassertion+xml

Introduction
      This document defines a MIME media type --
      application/samlassertion+xml -- for use with the XML serialization
      of SAML (Security Assertion Markup Language) assertions.

      The SAML specification sets -- [SAMLv1.0], [SAMLv1.1], [SAMLv2.0] --
      are work products of the OASIS Security Services Technical Committee
      [SSTC]. The SAML specifications define XML-based constructs with
      which one may make, and convey, security assertions. Using SAML, one
      can assert that an authentication event pertaining to some subject
      has occured and convey said assertion to a relying party, for
      example.

      SAML assertions, which are explicitly versioned, are defined by
      [SAMLv1Core], [SAMLv11Core], and [SAMLv2Core].

MIME media type name: application

MIME subtype name: saml+xml

Required parameters: none

Optional parameters: charset
      Same as charset parameter of application/xml [RFC3023].

Encoding considerations:
      Same as for application/xml [RFC3023].

Security considerations:
      Per their specification, samlassertion+xml typed objects do not
      contain executable content. However, SAML assertions are XML-based
      objects [XML]. As such, they have all of the general security
      considerations presented in section 10 of [RFC3023], as well as
      additional ones, since they are explicit security objects. For
      example, samlassertion+xml typed objects will often contain data
      that may identify or pertain to a natural person, and may be used as
      a basis for sessions and access control decisions.

      To counter potential issues, samlassertion+xml typed objects contain
      data that should be signed appropriately by the sender. Any such
      signature must be verified by the recipient of the data - both as a
      valid signature, and as being the signature of the sender. Issuers
      of samlassertion+xml objects containing SAMLv2 assertions may also
      encrypt all, or portions of, the assertions [SAMLv2Core].

      In addition, SAML profiles and protocol bindings specify use of
      secure channels as appropriate.

      [SAMLv2.0] incorporates various privacy-protection techniques in its
      design. For example: opaque handles, specific to interactions
      between specific system entities, are assigned to subjects. The
      handles are mappable to wider-context identifiers (e.g. email
      addresses, account identifiers, etc) by only the specific parties.

      For a more detailed discussion of SAML security considerations and
      specific security-related design techniques, please refer to the
      SAML specifications listed in the below bibliography. The
      specifications containing security-specific information have been
      explicitly listed for each version of SAML.

Interoperability considerations:
      SAML assertions are explicitly versioned. Relying parties should
      ensure that they observe assertion version information and behave
      accordingly. See "Chapter 4 SAML Versioning" in [SAMLv1Core],
      [SAMLv11Core], or [SAMLv2Core], as appropriate.

Published specification:
      [SAMLv2Bind] explicitly specifies use of the
      application/samlassertion+xml MIME media type. However, it is
      conceivable that non-SAMLv2 assertions (i.e. SAMLv1 and/or SAMLv1.1)
      might in practice be conveyed using SAMLv2 bindings.

Applications which use this media type:
      Potentially any application implementing SAML, as well as those
      applications implementing specifications based on SAML, e.g. those
      available from the Liberty Alliance [LAP].

Additional information:

      Magic number(s):
           In general, the same as for application/xml [RFC3023]. In
           particular, the XML root element of the returned object will be
           <saml:Assertion>, where "saml" maps to a version-specific SAML
           assertion namespace, as defined by the appropriate SAML "core"
           specification (see bibliography). In the case of SAMLv2.0, the
           root element of the returned object may be either
           <saml:Assertion> or <saml:EncryptedAssertion>, where "saml"
           maps to the SAMLv2.0 assertion namespace:
           urn:oasis:names:tc:SAML:2.0:assertion

      File extension(s): none
      Macintosh File Type Code(s): none

Person & email address to contact for further information:
      This registration is made on behalf of the OASIS Security Services
      Technical Committee (SSTC) Please refer to the SSTC website for
      current information on committee chairperson(s) and their contact
      addresses: http://www.oasis-open.org/committees/security/. Committee
      members should submit comments and potential errata to the
      [email-masked] list. Others should submit
      them by filling out the web form located at
      http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=secur

      Additionally, the SAML developer community email distribution list,
      [email-masked], may be employed to discuss usage of
      the application/samlassertion+xml MIME media type. The "saml-dev"
      mailing list is publicly archived here:
      http://lists.oasis-open.org/archives/saml-dev/. To post to the
      "saml-dev" mailing list, one must subscribe to it. To subscribe,
      send a message with the single word "subscribe" in the message body,
      to: [email-masked].

Intended usage: COMMON

Author/Change controller:
      The SAML specification sets are a work product of the OASIS Security
      Services Technical Committee (SSTC). OASIS and the SSTC have change
      control over the SAML specification sets.

Bibliography

      [LAP]          "Liberty Alliance Project". See
                     http://www.projectliberty.org/

      [OASIS]        "Organization for the Advancement of Structured
                     Information Systems". See http://www.oasis-open.org/

      [RFC3023]      M. Murata, S. St.Laurent, D. Kohn, "XML Media Types",
                     IETF Request for Comments 3023, January 2001. Available
                     as http://www.rfc-editor.org/rfc/rfc3023.txt

      [SAMLv1.0]     OASIS Security Services Technical Committee, "Security
                     Assertion Markup Language (SAML) Version 1.0
                     Specification Set". OASIS Standard 200205, November
                     2002. Available as
                     http://www.oasis-open.org/committees/download.php/2290/
                     oasis-sstc-saml-1.0.zip

      [SAMLv1Bind]   Prateek Mishra et al., "Bindings and Profiles for the
                     OASIS Security Assertion Markup Language (SAML)",
                     OASIS, November 2002. Document ID
                     oasis-sstc-saml-bindings-1.0. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv1Core]   Phillip Hallam-Baker et al., "Assertions and Protocol
                     for the OASIS Security Assertion Markup Language
                     (SAML)", OASIS, November 2002. Document ID
                     oasis-sstc-saml-core-1.0. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv1Sec]    Chris McLaren et al., "Security Considerations for the
                     OASIS Security Assertion Markup Language (SAML)",
                     OASIS, November 2002. Document ID
                     oasis-sstc-saml-sec-consider-1.0. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv1.1]     OASIS Security Services Technical Committee, "Security
                     Assertion Markup Language (SAML) Version 1.1
                     Specification Set". OASIS Standard 200308, August
                     2003. Available as
                     http://www.oasis-open.org/committees/download.php/3400/
                     oasis-sstc-saml-1.1-pdf-xsd.zip

      [SAMLv11Bind]  E. Maler et al. "Bindings and Profiles for the OASIS
                     Security Assertion Markup Language (SAML)". OASIS,
                     September 2003. Document ID
                     oasis-sstc-saml-bindings-1.1.
                     http://www.oasis-open.org/committees/security/

      [SAMLv11Core]  E. Maler et al. "Assertions and Protocol for the OASIS
                     Security Assertion Markup Language (SAML)". OASIS,
                     September 2003. Document ID oasis-sstc-saml-core-1.1.
                     http://www.oasis-open.org/committees/security/

      [SAMLv11Sec]   E. Maler et al. "Security Considerations for the OASIS
                     Security Assertion Markup Language (SAML)". OASIS,
                     September 2003. Document ID
                     oasis-sstc-saml-sec-consider-1.1.
                     http://www.oasis-open.org/committees/security/

      [SAMLv2.0]     OASIS Security Services Technical Committee, "Security
                     Assertion Markup Language (SAML) Version 2.0
                     Specification Set". WORK IN PROGRESS. Available at
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Bind]   S. Cantor et al., "Bindings for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS SSTC,
                     August 2004. Document ID
                     sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Core]   S. Cantor et al., "Assertions and Protocols for the
                     OASIS Security Assertion Markup Language (SAML)
                     V2.0". OASIS SSTC, August 2004. Document ID
                     sstc-saml-core-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Prof]   S. Cantor et al., "Profiles for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS SSTC,
                     August 2004. Document ID
                     sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Sec]    F. Hirsch et al., "Security and Privacy Considerations
                     for the OASIS Security Assertion Markup Language
                     (SAML) V2.0". OASIS SSTC, August 2004, WORK IN
                     PROGRESS. Document ID
                     sstc-saml-sec-consider-2.0-cd-01. See
                     http://www.oasis-open.org/committees/security/

      [SSTC]        "OASIS Security Services Technical Committee". See
                     http://www.oasis-open.org/committees/security/

      [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler,
                     "Extensible Markup Language (XML) 1.0 (Second
                     Edition)", World Wide Web Consortium Recommendation
                     REC-xml, October 2000, Available as
                     http://www.w3.org/TR/REC-xml

---
end

From: Jeff.Hodges at Sun.COM (Jeff Hodges)
Date: Tue Jan  3 16:22:46 2006
Subject: DRAFT Registration of MIME media type application/samlassertion+xml
Message-ID: <[email-masked]>

comments appreciated...

thanks,
JeffH
-----

<NOTE:
Registration of MIME media type application/samlassertion+xml
sstc-saml-2.0-application-samlassertion-registration-00
Jeff Hodges <[email-masked]>
21-Aug-2004

This document supersedes draft-hodges-saml-mediatype-02.txt. It
is intended to be included in sstc-saml-bindings-2.0-cd-02 (ie the next
time [SAMLv2Bind] is rev'd) as an appendix.

For an overview of the intricities involved when a non-IETF organization
registers a MIME media type in the "standards tree" (aka "IETF tree"),
please see http://www.w3.org/2002/06/registering-mediatype.html.

The below registration material is intended to satisfy the requirements
stated in draft-freed-media-type-reg-01.txt (which superseded
draft-freed-mime-p4-04.txt).

This "NOTE" is intended to be removed upon copying this document's
content into [SAMLv2Bind].

Acknowledgments: Thanks to Ned Freed and Larry Masinter for their
comments on a prior draft of this registration. The security
considerations section leverages that of
http://www.iana.org/assignments/media-types/application/vnd.paos+xml, by
John Kemp.
 >

To: [email-masked]
Subject: Registration of MIME media type application/samlassertion+xml

Introduction
      This document defines a MIME media type --
      application/samlassertion+xml -- for use with the XML serialization
      of SAML (Security Assertion Markup Language) assertions.

      The SAML specification sets -- [SAMLv1.0], [SAMLv1.1], [SAMLv2.0] --
      are work products of the OASIS Security Services Technical Committee
      [SSTC]. The SAML specifications define XML-based constructs with
      which one may make, and convey, security assertions. Using SAML, one
      can assert that an authentication event pertaining to some subject
      has occured and convey said assertion to a relying party, for
      example.

      SAML assertions, which are explicitly versioned, are defined by
      [SAMLv1Core], [SAMLv11Core], and [SAMLv2Core].

MIME media type name: application

MIME subtype name: saml+xml

Required parameters: none

Optional parameters: charset
      Same as charset parameter of application/xml [RFC3023].

Encoding considerations:
      Same as for application/xml [RFC3023].

Security considerations:
      Per their specification, samlassertion+xml typed objects do not
      contain executable content. However, SAML assertions are XML-based
      objects [XML]. As such, they have all of the general security
      considerations presented in section 10 of [RFC3023], as well as
      additional ones, since they are explicit security objects. For
      example, samlassertion+xml typed objects will often contain data
      that may identify or pertain to a natural person, and may be used as
      a basis for sessions and access control decisions.

      To counter potential issues, samlassertion+xml typed objects contain
      data that should be signed appropriately by the sender. Any such
      signature must be verified by the recipient of the data - both as a
      valid signature, and as being the signature of the sender. Issuers
      of samlassertion+xml objects containing SAMLv2 assertions may also
      encrypt all, or portions of, the assertions [SAMLv2Core].

      In addition, SAML profiles and protocol bindings specify use of
      secure channels as appropriate.

      [SAMLv2.0] incorporates various privacy-protection techniques in its
      design. For example: opaque handles, specific to interactions
      between specific system entities, are assigned to subjects. The
      handles are mappable to wider-context identifiers (e.g. email
      addresses, account identifiers, etc) by only the specific parties.

      For a more detailed discussion of SAML security considerations and
      specific security-related design techniques, please refer to the
      SAML specifications listed in the below bibliography. The
      specifications containing security-specific information have been
      explicitly listed for each version of SAML.

Interoperability considerations:
      SAML assertions are explicitly versioned. Relying parties should
      ensure that they observe assertion version information and behave
      accordingly. See "Chapter 4 SAML Versioning" in [SAMLv1Core],
      [SAMLv11Core], or [SAMLv2Core], as appropriate.

Published specification:
      [SAMLv2Bind] explicitly specifies use of the
      application/samlassertion+xml MIME media type. However, it is
      conceivable that non-SAMLv2 assertions (i.e. SAMLv1 and/or SAMLv1.1)
      might in practice be conveyed using SAMLv2 bindings.

Applications which use this media type:
      Potentially any application implementing SAML, as well as those
      applications implementing specifications based on SAML, e.g. those
      available from the Liberty Alliance [LAP].

Additional information:

      Magic number(s):
           In general, the same as for application/xml [RFC3023]. In
           particular, the XML root element of the returned object will be
           <saml:Assertion>, where "saml" maps to a version-specific SAML
           assertion namespace, as defined by the appropriate SAML "core"
           specification (see bibliography). In the case of SAMLv2.0, the
           root element of the returned object may be either
           <saml:Assertion> or <saml:EncryptedAssertion>, where "saml"
           maps to the SAMLv2.0 assertion namespace:
           urn:oasis:names:tc:SAML:2.0:assertion

      File extension(s): none
      Macintosh File Type Code(s): none

Person & email address to contact for further information:
      This registration is made on behalf of the OASIS Security Services
      Technical Committee (SSTC) Please refer to the SSTC website for
      current information on committee chairperson(s) and their contact
      addresses: http://www.oasis-open.org/committees/security/. Committee
      members should submit comments and potential errata to the
      [email-masked] list. Others should submit
      them by filling out the web form located at
      http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=secur

      Additionally, the SAML developer community email distribution list,
      [email-masked], may be employed to discuss usage of
      the application/samlassertion+xml MIME media type. The "saml-dev"
      mailing list is publicly archived here:
      http://lists.oasis-open.org/archives/saml-dev/. To post to the
      "saml-dev" mailing list, one must subscribe to it. To subscribe,
      send a message with the single word "subscribe" in the message body,
      to: [email-masked].

Intended usage: COMMON

Author/Change controller:
      The SAML specification sets are a work product of the OASIS Security
      Services Technical Committee (SSTC). OASIS and the SSTC have change
      control over the SAML specification sets.

Bibliography

      [LAP]          "Liberty Alliance Project". See
                     http://www.projectliberty.org/

      [OASIS]        "Organization for the Advancement of Structured
                     Information Systems". See http://www.oasis-open.org/

      [RFC3023]      M. Murata, S. St.Laurent, D. Kohn, "XML Media Types",
                     IETF Request for Comments 3023, January 2001. Available
                     as http://www.rfc-editor.org/rfc/rfc3023.txt

      [SAMLv1.0]     OASIS Security Services Technical Committee, "Security
                     Assertion Markup Language (SAML) Version 1.0
                     Specification Set". OASIS Standard 200205, November
                     2002. Available as
                     http://www.oasis-open.org/committees/download.php/2290/
                     oasis-sstc-saml-1.0.zip

      [SAMLv1Bind]   Prateek Mishra et al., "Bindings and Profiles for the
                     OASIS Security Assertion Markup Language (SAML)",
                     OASIS, November 2002. Document ID
                     oasis-sstc-saml-bindings-1.0. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv1Core]   Phillip Hallam-Baker et al., "Assertions and Protocol
                     for the OASIS Security Assertion Markup Language
                     (SAML)", OASIS, November 2002. Document ID
                     oasis-sstc-saml-core-1.0. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv1Sec]    Chris McLaren et al., "Security Considerations for the
                     OASIS Security Assertion Markup Language (SAML)",
                     OASIS, November 2002. Document ID
                     oasis-sstc-saml-sec-consider-1.0. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv1.1]     OASIS Security Services Technical Committee, "Security
                     Assertion Markup Language (SAML) Version 1.1
                     Specification Set". OASIS Standard 200308, August
                     2003. Available as
                     http://www.oasis-open.org/committees/download.php/3400/
                     oasis-sstc-saml-1.1-pdf-xsd.zip

      [SAMLv11Bind]  E. Maler et al. "Bindings and Profiles for the OASIS
                     Security Assertion Markup Language (SAML)". OASIS,
                     September 2003. Document ID
                     oasis-sstc-saml-bindings-1.1.
                     http://www.oasis-open.org/committees/security/

      [SAMLv11Core]  E. Maler et al. "Assertions and Protocol for the OASIS
                     Security Assertion Markup Language (SAML)". OASIS,
                     September 2003. Document ID oasis-sstc-saml-core-1.1.
                     http://www.oasis-open.org/committees/security/

      [SAMLv11Sec]   E. Maler et al. "Security Considerations for the OASIS
                     Security Assertion Markup Language (SAML)". OASIS,
                     September 2003. Document ID
                     oasis-sstc-saml-sec-consider-1.1.
                     http://www.oasis-open.org/committees/security/

      [SAMLv2.0]     OASIS Security Services Technical Committee, "Security
                     Assertion Markup Language (SAML) Version 2.0
                     Specification Set". WORK IN PROGRESS. Available at
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Bind]   S. Cantor et al., "Bindings for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS SSTC,
                     August 2004. Document ID
                     sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Core]   S. Cantor et al., "Assertions and Protocols for the
                     OASIS Security Assertion Markup Language (SAML)
                     V2.0". OASIS SSTC, August 2004. Document ID
                     sstc-saml-core-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Prof]   S. Cantor et al., "Profiles for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS SSTC,
                     August 2004. Document ID
                     sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Sec]    F. Hirsch et al., "Security and Privacy Considerations
                     for the OASIS Security Assertion Markup Language
                     (SAML) V2.0". OASIS SSTC, August 2004, WORK IN
                     PROGRESS. Document ID
                     sstc-saml-sec-consider-2.0-cd-01. See
                     http://www.oasis-open.org/committees/security/

      [SSTC]        "OASIS Security Services Technical Committee". See
                     http://www.oasis-open.org/committees/security/

      [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler,
                     "Extensible Markup Language (XML) 1.0 (Second
                     Edition)", World Wide Web Consortium Recommendation
                     REC-xml, October 2000, Available as
                     http://www.w3.org/TR/REC-xml

---
end

From: Jeff.Hodges at Sun.COM (Jeff Hodges)
Date: Sat Aug 21 21:32:32 2004
Subject: draft-hodges-saml-mediatype-01
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Larry, thanks for the comments, they're helpful. I'll post a revision of 
draft-hodges-saml-mediatype-01 (tho no longer cast in the form of an I-D) in a 
subsequent message.

JeffH

From: Jeff.Hodges at Sun.COM (Jeff Hodges)
Date: Tue Jan  3 16:22:46 2006
Subject: draft-hodges-saml-mediatype-01
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Larry, thanks for the comments, they're helpful. I'll post a revision of 
draft-hodges-saml-mediatype-01 (tho no longer cast in the form of an I-D) in a 
subsequent message.

JeffH

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Thu Sep 16 09:16:30 2004
Subject: draft-hodges-saml-mediatype-01 
In-Reply-To: Larry Masinter <[email-masked]> 's message of  Thu, 24 Jun 2004 11:39:24 -0700
Message-ID: <[email-masked]>

Larry -- thanks for the feedback on that earlier I-D, it was helpful. I'll 
post a revision to draft-hodges-saml-mediatype-01 (but no longer in the form 
of an I-D) in a subsequent message.

JeffH

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Jan  3 16:22:47 2006
Subject: draft-hodges-saml-mediatype-01 
In-Reply-To: Larry Masinter <[email-masked]> 's message of  Thu, 24 Jun 2004 11:39:24 -0700
Message-ID: <[email-masked]>

Larry -- thanks for the feedback on that earlier I-D, it was helpful. I'll 
post a revision to draft-hodges-saml-mediatype-01 (but no longer in the form 
of an I-D) in a subsequent message.

JeffH

From: Jeff.Hodges at Sun.COM (Jeff Hodges)
Date: Sat Aug 21 21:10:42 2004
Subject: draft-freed-mime-p4-04 is apparently superseded by..
Message-ID: <[email-masked]>

draft-freed-mime-p4-05
http://www.ietf.org/internet-drafts/draft-freed-mime-p4-05.txt

draft-freed-media-type-reg-01
http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt

MartinD or whomever might want to update their very nice page..

  How to Register a Media Type with IANA (for the IETF tree)
  http://www.w3.org/2002/06/registering-mediatype.html

thanks,

JeffH

From: Jeff.Hodges at Sun.COM (Jeff Hodges)
Date: Tue Jan  3 16:22:46 2006
Subject: draft-freed-mime-p4-04 is apparently superseded by..
Message-ID: <[email-masked]>

draft-freed-mime-p4-05
http://www.ietf.org/internet-drafts/draft-freed-mime-p4-05.txt

draft-freed-media-type-reg-01
http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt

MartinD or whomever might want to update their very nice page..

  How to Register a Media Type with IANA (for the IETF tree)
  http://www.w3.org/2002/06/registering-mediatype.html

thanks,

JeffH

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Jan  3 16:22:47 2006
Subject: fyi: draft-freed-mime-p4-04 morphs into draft-freed-media-type-reg-01 and draft-freed-mime-p4-05
Message-ID: <[email-masked]>

Note that draft-freed-mime-p4-04 has been apparently superseded by 
draft-freed-media-type-reg-01 and draft-freed-mime-p4-05

MartinD -- your nice page..

  http://www.w3.org/2002/06/registering-mediatype.html

..will need some minor updating. 

JeffH

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:46 2006
Subject: Pre review of 3GPP MIME type for RTP payload format
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Part of the problem is that RFC 3555 (MIME Type Registration
of RTP Payload Types) isn't marked as updating RFC 2048, even though
it seems to be intended to.

> [mw]
> The fact is that RTP and its signalling do require the 
> registration in the applicable. For RTP there is a clear 
> explanation in RFC 3550 why it is harmful to mix different 
> media types in the same RTP session. Due to this reason also 
> the signalling in SDP does not allow the mixing of multiple 
> media types in the same RTP session. So due to the above 
> restrictions one can not register an single 
> application/rtp.enc.aes128 to secure all the different media 
> top levels. 
> [\mw]

I looked at RFC 3550, and can find no mention
of MIME or any references to the media type registry,
so I don't understand where this 'clear explanation'
might be. There is a definition of a 'RTP media type':

   RTP media type: An RTP media type is the collection of payload
      types which can be carried within a single RTP session.  The RTP
      Profile assigns RTP media types to RTP payload types.

but I don't see what this has to do with MIME media types.
Can you be more explicit about where this is clearly explained?

It's hard to trace from 3555 and 3550 to the requirement that
different kinds of data need different top-level text/ audio/
video/ types.

Larry

From: rey at panasonic.de (Jose Rey)
Date: Tue Jan  3 16:22:48 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Colin, all,

Dave and I have been discussing this offline and come to the following
conclusions:

1.- it is not envisioned that the 3GPP Timed Text payload format will be
used for applications such as instant messaging or text conversation, which
do not precise of text decoration for working properly, since there are
other more appropriate media types covering these usages, like text/t140.
Hence,  video/ is enough.

2.- we are not clear on what exactly means to "relax rules for media
registration under text/".  I.e. is text/t140 an example of these "relaxed"
rules or does it comply with the traditional rules as per rfc 2046?  Does
the relaxed rules just mean that besides text also payload headers of that
media type are udnerstood?

We would appreciate your feedback,

Jose

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jose Rey
> Sent: Monday, August 16, 2004 5:39 PM
> To: Dave Singer; Colin Perkins
> Cc: Magnus Westerlund; IETF AVT WG
> Subject: RE: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
> andMediaTypes)
>
>
>
> Dave, Colin,
>
> --cut--
> > >
> > >If this analysis is OK, we could register both and clearly state the
> > >scenarios in which each of them is used.  This would enable a
> client that
> > >just understands UTF8/16 and the payload format to receive the
> > text/3gpp-tt
> > >w/o implementing the more complex timed text decoder, which may
> > be useful.
> > >A side effect of using this classification is that the
> registration *does
> > >implicitly* follow the traditional rules.
> > >
> > >Looking forward to your comments,
> > >
> >
> > Since this payload format always has some binary fields, the text
> > cannot be correctly extracted without understanding it, whether or
> > not modifiers are present.
>
> As Colin said, for limited domains of applicability you can also register
> under text/, without complying with the traditional rules:
>
> "The slides you quote are my interpretation of the traditional rules for
> media under the "text" top level type. As you know, there has been some
> discussion on relaxing these rules for media types with limited domain
> of applicability. The RTP Payload Format for 3GPP timed text might fall
> into this new category. Accordingly, we have this MIME review to decide
> if the format should be "text" or "video"."
>
>
> >  I therefore feel that it should be either
> > (a) only under text/ or (b) only under video/.  I don't see any
> > advantage to splitting it like this;  the 3gpp-payload-unaware
> > terminal can't make any more sense of a packet without modifiers than
> > it can one with them.
>
> Therefore I don't think this is the criteria to judge text/ it appropriate
> or not, but rather whether there are differentiated domains of
> applicability
> for which the timed text format can be used. In my previous email
> I tried to
> classify intuitively in those that need just text and the ones that need
> text AND video.
>
> The answer to this different question might as well be no ;), but
> I had the
> feeling we talked past each other.
>
> Cheers,
>
> Jose
>
> PS: Colin, would RTP payload headers be part of the "software that
> understands it"?)
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
>

From: magnus.westerlund at ericsson.com (Magnus Westerlund (KI/EAB))
Date: Mon Aug 16 10:25:23 2004
Subject: Pre review of 3GPP MIME type for RTP payload format
Message-ID: <[email-masked]>

Hi Larry,

Comments below, prefixed with [mw]. 

-----Original Message-----
From: Larry Masinter
To: Magnus Westerlund (KI/EAB)
Cc: [email-masked]
Sent: 2004-08-16 08:37
Subject: RE: Pre review of 3GPP MIME type for RTP payload format

> The problem is that the RTP payload format this defines is capable of 
> wrapping any other payload format.

Yes, the 'application' is the 'application as a wrapping technology'.

> As any other payload format 
> theoretically has any of the media types, this format needs to handle 
> all of the types. 

This isn't inconsistent with using 'application'.

[mw]
Yes, I would agree with you in the general context. However things are not this simple in the RTP usage domain. I will try to explain reasons why RTP payload formats that apply to different media types needs to be registered in multiple media types. 
[\mw] 

> So from my perspective, I don't see a problem with removing "Image"
and 
> "application" from the registration. The other three are needed.

I think we differ on the meaning of the top level media type. You
imagine that you need to use 'image' when the body is an image,
and I don't think it is necessary at all.

[mw]
The fact is that RTP and its signalling do require the registration in the applicable. For RTP there is a clear explanation in RFC 3550 why it is harmful to mix different media types in the same RTP session. Due to this reason also the signalling in SDP does not allow the mixing of multiple media types in the same RTP session. So due to the above restrictions one can not register an single application/rtp.enc.aes128 to secure all the different media top levels. 
[\mw]

I think it is harmful to register multiple media types when one will
do nicely. It isn't necessary that every MIME label be completely
descriptive of the content, but just that the MIME label contain
sufficient information to find the appropriate reciever.

[mw]
There is actuallly a good thing with registering in each media type for format that applies to one or all. That way one can ensure that a format actually is applicable to that media type. If one only register a single format, then there is not the same foral check that the usage for a certain meda type actually is applicable. For example the audio/RED mime type which we are now registering as text/RED when it has been checked that it is applicable.
[\mw]

And, since you can't do anything with the content without decrypting
it, and leaking information about the content is a concern, why not
just use 'application' all the time? Like with ZIP files or PDF files.

[mw]
In the RTP framework you are required to leak what media type in the signalling path anyway. You will need to secure the signalling path individually to the desired security level. 

I am sorry that the kinks of the RTP payload format MIME registrations procceduers was not worked out years ago. Today when we have several years of baggage, changing things are difficult. Please take a look at RFC 3555 whith outline the RTP MIME registration procedures. We do know that we will need to probably update this document when the new MIME registration rules are agreed on. 
[\mw]

Cheers

Magnus Westerlund
>From [email-masked]  Tue Aug 17 20:03:34 2004
From: LMM at acm.org (Larry Masinter)
Date: Tue Aug 17 20:04:05 2004
Subject: Pre review of 3GPP MIME type for RTP payload format
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Part of the problem is that RFC 3555 (MIME Type Registration
of RTP Payload Types) isn't marked as updating RFC 2048, even though
it seems to be intended to.

> [mw]
> The fact is that RTP and its signalling do require the 
> registration in the applicable. For RTP there is a clear 
> explanation in RFC 3550 why it is harmful to mix different 
> media types in the same RTP session. Due to this reason also 
> the signalling in SDP does not allow the mixing of multiple 
> media types in the same RTP session. So due to the above 
> restrictions one can not register an single 
> application/rtp.enc.aes128 to secure all the different media 
> top levels. 
> [\mw]

I looked at RFC 3550, and can find no mention
of MIME or any references to the media type registry,
so I don't understand where this 'clear explanation'
might be. There is a definition of a 'RTP media type':

   RTP media type: An RTP media type is the collection of payload
      types which can be carried within a single RTP session.  The RTP
      Profile assigns RTP media types to RTP payload types.

but I don't see what this has to do with MIME media types.
Can you be more explicit about where this is clearly explained?

It's hard to trace from 3555 and 3550 to the requirement that
different kinds of data need different top-level text/ audio/
video/ types.

Larry

From: magnus.westerlund at ericsson.com (Magnus Westerlund (KI/EAB))
Date: Tue Jan  3 16:22:46 2006
Subject: Pre review of 3GPP MIME type for RTP payload format
Message-ID: <[email-masked]>

Hi Larry,

Comments below, prefixed with [mw]. 

-----Original Message-----
From: Larry Masinter
To: Magnus Westerlund (KI/EAB)
Cc: [email-masked]
Sent: 2004-08-16 08:37
Subject: RE: Pre review of 3GPP MIME type for RTP payload format

> The problem is that the RTP payload format this defines is capable of 
> wrapping any other payload format.

Yes, the 'application' is the 'application as a wrapping technology'.

> As any other payload format 
> theoretically has any of the media types, this format needs to handle 
> all of the types. 

This isn't inconsistent with using 'application'.

[mw]
Yes, I would agree with you in the general context. However things are not this simple in the RTP usage domain. I will try to explain reasons why RTP payload formats that apply to different media types needs to be registered in multiple media types. 
[\mw] 

> So from my perspective, I don't see a problem with removing "Image"
and 
> "application" from the registration. The other three are needed.

I think we differ on the meaning of the top level media type. You
imagine that you need to use 'image' when the body is an image,
and I don't think it is necessary at all.

[mw]
The fact is that RTP and its signalling do require the registration in the applicable. For RTP there is a clear explanation in RFC 3550 why it is harmful to mix different media types in the same RTP session. Due to this reason also the signalling in SDP does not allow the mixing of multiple media types in the same RTP session. So due to the above restrictions one can not register an single application/rtp.enc.aes128 to secure all the different media top levels. 
[\mw]

I think it is harmful to register multiple media types when one will
do nicely. It isn't necessary that every MIME label be completely
descriptive of the content, but just that the MIME label contain
sufficient information to find the appropriate reciever.

[mw]
There is actuallly a good thing with registering in each media type for format that applies to one or all. That way one can ensure that a format actually is applicable to that media type. If one only register a single format, then there is not the same foral check that the usage for a certain meda type actually is applicable. For example the audio/RED mime type which we are now registering as text/RED when it has been checked that it is applicable.
[\mw]

And, since you can't do anything with the content without decrypting
it, and leaking information about the content is a concern, why not
just use 'application' all the time? Like with ZIP files or PDF files.

[mw]
In the RTP framework you are required to leak what media type in the signalling path anyway. You will need to secure the signalling path individually to the desired security level. 

I am sorry that the kinks of the RTP payload format MIME registrations procceduers was not worked out years ago. Today when we have several years of baggage, changing things are difficult. Please take a look at RFC 3555 whith outline the RTP MIME registration procedures. We do know that we will need to probably update this document when the new MIME registration rules are agreed on. 
[\mw]

Cheers

Magnus Westerlund

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:45 2006
Subject: Pre review of 3GPP MIME type for RTP payload format
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> The problem is that the RTP payload format this defines is capable of 
> wrapping any other payload format.

Yes, the 'application' is the 'application as a wrapping technology'.

> As any other payload format 
> theoretically has any of the media types, this format needs to handle 
> all of the types. 

This isn't inconsistent with using 'application'.
 
> So from my perspective, I don't see a problem with removing "Image" and 
> "application" from the registration. The other three are needed.

I think we differ on the meaning of the top level media type. You
imagine that you need to use 'image' when the body is an image,
and I don't think it is necessary at all.

I think it is harmful to register multiple media types when one will
do nicely. It isn't necessary that every MIME label be completely
descriptive of the content, but just that the MIME label contain
sufficient information to find the appropriate reciever.

And, since you can't do anything with the content without decrypting
it, and leaking information about the content is a concern, why not
just use 'application' all the time? Like with ZIP files or PDF files.

Larry

From: singer at apple.com (Dave Singer)
Date: Thu Sep 16 09:16:59 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMedia  Types)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <p0610057fbd429cb4a4c8@[17.202.35.52]>

>  >
>>  The slides you quote are my interpretation of the traditional rules for
>>  media under the "text" top level type. As you know, there has been some
>>  discussion on relaxing these rules for media types with limited domain
>>  of applicability. The RTP Payload Format for 3GPP timed text might fall
>>  into this new category. Accordingly, we have this MIME review to decide
>>  if the format should be "text" or "video".
>
>Thanks for your answer. So we have that *only* registering for a wider
>domain of applicability would require to follow the *traditional* rules.
>
>Would one criteria for assessing the domain of applicability be to group the
>use cases in those that don't need modifiers and those that do? This is
>intuitive. I.e.:
>
>simple text apps (require no modifiers= no video requirements, thus
>text/3gpp-tt?)
>-----------
>- instant messaging
>- text conversation
>- other..
>
>more complex apps (have video reqs.)
>------------------
>- commercial banners (decorated)
>- news tickers (decorated)
>- karaoke
>- clickable text strings
>- captions (although most captions don't need modifiers, some do e.g.
>scrolling end actors' list)
>
>If this analysis is OK, we could register both and clearly state the
>scenarios in which each of them is used.  This would enable a client that
>just understands UTF8/16 and the payload format to receive the text/3gpp-tt
>w/o implementing the more complex timed text decoder, which may be useful.
>A side effect of using this classification is that the registration *does
>implicitly* follow the traditional rules.
>
>Looking forward to your comments,
>

Since this payload format always has some binary fields, the text 
cannot be correctly extracted without understanding it, whether or 
not modifiers are present.  I therefore feel that it should be either 
(a) only under text/ or (b) only under video/.  I don't see any 
advantage to splitting it like this;  the 3gpp-payload-unaware 
terminal can't make any more sense of a packet without modifiers than 
it can one with them.
-- 
David Singer
Apple Computer/QuickTime
>From [email-masked]  Tue Aug 17 15:43:05 2004
From: rey at panasonic.de (Jose Rey)
Date: Thu Sep 16 09:17:02 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
	andMediaTypes)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Colin, all,

Dave and I have been discussing this offline and come to the following
conclusions:

1.- it is not envisioned that the 3GPP Timed Text payload format will be
used for applications such as instant messaging or text conversation, which
do not precise of text decoration for working properly, since there are
other more appropriate media types covering these usages, like text/t140.
Hence,  video/ is enough.

2.- we are not clear on what exactly means to "relax rules for media
registration under text/".  I.e. is text/t140 an example of these "relaxed"
rules or does it comply with the traditional rules as per rfc 2046?  Does
the relaxed rules just mean that besides text also payload headers of that
media type are udnerstood?

We would appreciate your feedback,

Jose

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jose Rey
> Sent: Monday, August 16, 2004 5:39 PM
> To: Dave Singer; Colin Perkins
> Cc: Magnus Westerlund; IETF AVT WG
> Subject: RE: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
> andMediaTypes)
>
>
>
> Dave, Colin,
>
> --cut--
> > >
> > >If this analysis is OK, we could register both and clearly state the
> > >scenarios in which each of them is used.  This would enable a
> client that
> > >just understands UTF8/16 and the payload format to receive the
> > text/3gpp-tt
> > >w/o implementing the more complex timed text decoder, which may
> > be useful.
> > >A side effect of using this classification is that the
> registration *does
> > >implicitly* follow the traditional rules.
> > >
> > >Looking forward to your comments,
> > >
> >
> > Since this payload format always has some binary fields, the text
> > cannot be correctly extracted without understanding it, whether or
> > not modifiers are present.
>
> As Colin said, for limited domains of applicability you can also register
> under text/, without complying with the traditional rules:
>
> "The slides you quote are my interpretation of the traditional rules for
> media under the "text" top level type. As you know, there has been some
> discussion on relaxing these rules for media types with limited domain
> of applicability. The RTP Payload Format for 3GPP timed text might fall
> into this new category. Accordingly, we have this MIME review to decide
> if the format should be "text" or "video"."
>
>
> >  I therefore feel that it should be either
> > (a) only under text/ or (b) only under video/.  I don't see any
> > advantage to splitting it like this;  the 3gpp-payload-unaware
> > terminal can't make any more sense of a packet without modifiers than
> > it can one with them.
>
> Therefore I don't think this is the criteria to judge text/ it appropriate
> or not, but rather whether there are differentiated domains of
> applicability
> for which the timed text format can be used. In my previous email
> I tried to
> classify intuitively in those that need just text and the ones that need
> text AND video.
>
> The answer to this different question might as well be no ;), but
> I had the
> feeling we talked past each other.
>
> Cheers,
>
> Jose
>
> PS: Colin, would RTP payload headers be part of the "software that
> understands it"?)
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
>

From: singer at apple.com (Dave Singer)
Date: Tue Jan  3 16:22:48 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMedia  Types)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <p0610057fbd429cb4a4c8@[17.202.35.52]>

>  >
>>  The slides you quote are my interpretation of the traditional rules for
>>  media under the "text" top level type. As you know, there has been some
>>  discussion on relaxing these rules for media types with limited domain
>>  of applicability. The RTP Payload Format for 3GPP timed text might fall
>>  into this new category. Accordingly, we have this MIME review to decide
>>  if the format should be "text" or "video".
>
>Thanks for your answer. So we have that *only* registering for a wider
>domain of applicability would require to follow the *traditional* rules.
>
>Would one criteria for assessing the domain of applicability be to group the
>use cases in those that don't need modifiers and those that do? This is
>intuitive. I.e.:
>
>simple text apps (require no modifiers= no video requirements, thus
>text/3gpp-tt?)
>-----------
>- instant messaging
>- text conversation
>- other..
>
>more complex apps (have video reqs.)
>------------------
>- commercial banners (decorated)
>- news tickers (decorated)
>- karaoke
>- clickable text strings
>- captions (although most captions don't need modifiers, some do e.g.
>scrolling end actors' list)
>
>If this analysis is OK, we could register both and clearly state the
>scenarios in which each of them is used.  This would enable a client that
>just understands UTF8/16 and the payload format to receive the text/3gpp-tt
>w/o implementing the more complex timed text decoder, which may be useful.
>A side effect of using this classification is that the registration *does
>implicitly* follow the traditional rules.
>
>Looking forward to your comments,
>

Since this payload format always has some binary fields, the text 
cannot be correctly extracted without understanding it, whether or 
not modifiers are present.  I therefore feel that it should be either 
(a) only under text/ or (b) only under video/.  I don't see any 
advantage to splitting it like this;  the 3gpp-payload-unaware 
terminal can't make any more sense of a packet without modifiers than 
it can one with them.
-- 
David Singer
Apple Computer/QuickTime

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Fri Aug 13 16:46:42 2004
Subject: Pre review of 3GPP MIME type for RTP payload format
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Larry,

Thanks for taking a look.

Larry Masinter wrote:

>>MIME media type name: audio, video, text, application, image
> 
> 
> 'application' alone makes more sense than registering any
> of the rest.
> 

The problem is that the RTP payload format this defines is capable of 
wrapping any other payload format. As any other payload format 
theoretically has any of the media types, this format needs to handle 
all of the types. Currently there is MUST requirement to handle "audio" 
"video" and most likely "text" (depends somewhat on the result of the 
timed text discussion). "Application" and "Image" are kind of thrown in 
there for completeness. "model" "multipart" and "message" has so far not 
made any sense at all for RTP.

It is both RTP and the signalling that puts requirement on the media 
type for a wrapper payload format to be the same as what it wraps. 
Earlier IETF examples of this are the type audio/parityfec that are also 
registered in video, text.

So from my perspective, I don't see a problem with removing "Image" and 
"application" from the registration. The other three are needed.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
>From [email-masked]  Mon Aug 16 08:37:45 2004
From: LMM at acm.org (Larry Masinter)
Date: Mon Aug 16 08:38:00 2004
Subject: Pre review of 3GPP MIME type for RTP payload format
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> The problem is that the RTP payload format this defines is capable of 
> wrapping any other payload format.

Yes, the 'application' is the 'application as a wrapping technology'.

> As any other payload format 
> theoretically has any of the media types, this format needs to handle 
> all of the types. 

This isn't inconsistent with using 'application'.
 
> So from my perspective, I don't see a problem with removing "Image" and 
> "application" from the registration. The other three are needed.

I think we differ on the meaning of the top level media type. You
imagine that you need to use 'image' when the body is an image,
and I don't think it is necessary at all.

I think it is harmful to register multiple media types when one will
do nicely. It isn't necessary that every MIME label be completely
descriptive of the content, but just that the MIME label contain
sufficient information to find the appropriate reciever.

And, since you can't do anything with the content without decrypting
it, and leaking information about the content is a concern, why not
just use 'application' all the time? Like with ZIP files or PDF files.

Larry

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Tue Jan  3 16:22:45 2006
Subject: Pre review of 3GPP MIME type for RTP payload format
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Larry,

Thanks for taking a look.

Larry Masinter wrote:

>>MIME media type name: audio, video, text, application, image
> 
> 
> 'application' alone makes more sense than registering any
> of the rest.
> 

The problem is that the RTP payload format this defines is capable of 
wrapping any other payload format. As any other payload format 
theoretically has any of the media types, this format needs to handle 
all of the types. Currently there is MUST requirement to handle "audio" 
"video" and most likely "text" (depends somewhat on the result of the 
timed text discussion). "Application" and "Image" are kind of thrown in 
there for completeness. "model" "multipart" and "message" has so far not 
made any sense at all for RTP.

It is both RTP and the signalling that puts requirement on the media 
type for a wrapper payload format to be the same as what it wraps. 
Earlier IETF examples of this are the type audio/parityfec that are also 
registered in video, text.

So from my perspective, I don't see a problem with removing "Image" and 
"application" from the registration. The other three are needed.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:45 2006
Subject: Pre review of 3GPP MIME type for RTP payload format
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> MIME media type name: audio, video, text, application, image

'application' alone makes more sense than registering any
of the rest.

From: rey at panasonic.de (Jose Rey)
Date: Thu Sep 16 09:16:57 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMedia Types)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Friday, August 13, 2004 12:22 PM
> To: Jose Rey
> Cc: Magnus Westerlund; Dave Singer; IETF AVT WG; [email-masked]
> Subject: Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
> andMedia Types)
>
>
> On 12 Aug 2004, at 17:30, Jose Rey wrote:
> > Dave, Magnus
> >
> > --cut--
> >>>
> >>> As I said in my previous email, registering under 'text' top level
> >>> type would mean that the modifiers cannot be used.
> >>
> >> why is that true?  does text/* only admit of plain text?  so, for
> >> example, text/html would not be permitted either??
> >>
> >
> > This is what I understand from the slides from Colin presented during
> > the
> > meeting (see in http://www.dcs.gla.ac.uk/~csp/IETF60-AVT-Tue.zip,
> > "09-RTP-Media-Types.pdf"). Specially slide three where it says:
> >
> > ". In particular, it is expected that text media types are "to some
> > extent readable even without the software that interprets them"
> > - RFC 2046
> > - This rule is derived from email client behaviour; want to pass the
> > message
> > to a dumb pager if there's no better display option"
> >
> > Colin or Magnus may please correct me if I got it wrong...
>
> The slides you quote are my interpretation of the traditional rules for
> media under the "text" top level type. As you know, there has been some
> discussion on relaxing these rules for media types with limited domain
> of applicability. The RTP Payload Format for 3GPP timed text might fall
> into this new category. Accordingly, we have this MIME review to decide
> if the format should be "text" or "video".

Thanks for your answer. So we have that *only* registering for a wider
domain of applicability would require to follow the *traditional* rules.

Would one criteria for assessing the domain of applicability be to group the
use cases in those that don't need modifiers and those that do? This is
intuitive. I.e.:

simple text apps (require no modifiers= no video requirements, thus
text/3gpp-tt?)
-----------
- instant messaging
- text conversation
- other..

more complex apps (have video reqs.)
------------------
- commercial banners (decorated)
- news tickers (decorated)
- karaoke
- clickable text strings
- captions (although most captions don't need modifiers, some do e.g.
scrolling end actors' list)

If this analysis is OK, we could register both and clearly state the
scenarios in which each of them is used.  This would enable a client that
just understands UTF8/16 and the payload format to receive the text/3gpp-tt
w/o implementing the more complex timed text decoder, which may be useful.
A side effect of using this classification is that the registration *does
implicitly* follow the traditional rules.

Looking forward to your comments,

Thanks,

Jose

>
> --
> Colin Perkins
> http://csperkins.org/
>
>

From: rey at panasonic.de (Jose Rey)
Date: Tue Jan  3 16:22:47 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMedia Types)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Friday, August 13, 2004 12:22 PM
> To: Jose Rey
> Cc: Magnus Westerlund; Dave Singer; IETF AVT WG; [email-masked]
> Subject: Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
> andMedia Types)
>
>
> On 12 Aug 2004, at 17:30, Jose Rey wrote:
> > Dave, Magnus
> >
> > --cut--
> >>>
> >>> As I said in my previous email, registering under 'text' top level
> >>> type would mean that the modifiers cannot be used.
> >>
> >> why is that true?  does text/* only admit of plain text?  so, for
> >> example, text/html would not be permitted either??
> >>
> >
> > This is what I understand from the slides from Colin presented during
> > the
> > meeting (see in http://www.dcs.gla.ac.uk/~csp/IETF60-AVT-Tue.zip,
> > "09-RTP-Media-Types.pdf"). Specially slide three where it says:
> >
> > ". In particular, it is expected that text media types are "to some
> > extent readable even without the software that interprets them"
> > - RFC 2046
> > - This rule is derived from email client behaviour; want to pass the
> > message
> > to a dumb pager if there's no better display option"
> >
> > Colin or Magnus may please correct me if I got it wrong...
>
> The slides you quote are my interpretation of the traditional rules for
> media under the "text" top level type. As you know, there has been some
> discussion on relaxing these rules for media types with limited domain
> of applicability. The RTP Payload Format for 3GPP timed text might fall
> into this new category. Accordingly, we have this MIME review to decide
> if the format should be "text" or "video".

Thanks for your answer. So we have that *only* registering for a wider
domain of applicability would require to follow the *traditional* rules.

Would one criteria for assessing the domain of applicability be to group the
use cases in those that don't need modifiers and those that do? This is
intuitive. I.e.:

simple text apps (require no modifiers= no video requirements, thus
text/3gpp-tt?)
-----------
- instant messaging
- text conversation
- other..

more complex apps (have video reqs.)
------------------
- commercial banners (decorated)
- news tickers (decorated)
- karaoke
- clickable text strings
- captions (although most captions don't need modifiers, some do e.g.
scrolling end actors' list)

If this analysis is OK, we could register both and clearly state the
scenarios in which each of them is used.  This would enable a client that
just understands UTF8/16 and the payload format to receive the text/3gpp-tt
w/o implementing the more complex timed text decoder, which may be useful.
A side effect of using this classification is that the registration *does
implicitly* follow the traditional rules.

Looking forward to your comments,

Thanks,

Jose

>
> --
> Colin Perkins
> http://csperkins.org/
>
>

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Fri Aug 13 13:13:11 2004
Subject: Pre review of 3GPP MIME type for RTP payload format
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

We have detected a copy and paste error of the complete Appendix K in 
the first of the below references, and it has been replaced with the 
following version.

http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_32/Docs/S4-040481.zip

Cheers

Magnus

Magnus Westerlund wrote:

> Hi,
> 
> I would like to have a pre registration request review of the below 
> propsed MIME type for a RTP payload format. This registration request is 
> intended to use the updated registration procedure based on 
> specification available from other standards body.
> 
> The specification that the registration belongs to can be found in the 
> following 3GPP contribution:
> 
> http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_32/Docs/S4-040460.zip
> Which is the specification delta that included the RTP payload format 
> defined within to the following specification:
> 
> http://www.3gpp.org/ftp/Specs/latest/Rel-6/26_series/26234-600.zip
> 
> The registration template for this looks like the following:
> ------------------------------------------------------------
> 
> MIME media type name: audio, video, text, application, image
> 
> MIME subtype name: rtp.enc.aescm128
> 
> Required parameters:
> 
> opt:     The payload type number of the payload type contained in the
>         encrypted payload. An integer value between 0-127.
> 
> rate:     The timestamp rate of this payload type, which shall be the same
>         as that of the original payload type. This is an integer value
>         between 1 and 2^32.
> 
> ContentID: The OMA DRM content ID [75] used to identify the content when
>         establishing a crypto context. The value is an RFC 2396 [60]
>         URI, which shall be quoted using <">.
> 
> RightsIssuerURL: The right issuer URL as defined by OMA DRM [75]. The
>         value is an URI in accordance with RFC 2396 [60], which shall be
>         quoted using <">.
> 
> IVnonce: The value of this parameter is the nonce that forms the IV as
>         specified by the crypto transform, encoded using Base 64 [69].
> 
> Optional parameters:
> 
> SelectiveEncryption:     Indicates if this stream is selectively
>         encrypted. Allowed values are 0 (false) and 1 (true). If not
>         present, selective encryption shall not be used. Please note
>         that unless this indicator is integrity protected, it fulfils no
>         purpose.
> 
> Encoding considerations:
>         This type is only defined for transfer via RTP (RFC 3550).
> 
> Security considerations:
> 
> See considerations raised in RTP RFC 3550 [9] and any applicable
> profile like RFC 3551 [10] or RFC 3711 [72]. Further see 3GPP TS
> 26.234, Release 6, Annex K for comments on security issues. The main
> issues that exists are:
> 
> - This RTP payload format only confidentiality protects the RTP payload, 
> thus header information is leaked, similarly to SRTP.
> 
> - The use of stream ciphers as AES CM and no integrity protection allows 
> an attacker to purposefully attack the content of the encrypted RTP 
> payload by switching individual bits.
> 
> - The usage of selective encryption without integrity protection allows 
> for an attacker to perform any replacements of complete RTP payloads and 
> packets it desires.
> 
> - The payload format makes the receiver vulnerable to denial of service 
> attacks that inserts RTP packets into the stream, that the receiver then 
> interprets as being encrypted thus wasting computational resources. To 
> prevent this attack, authentication needs to be used.
> Interoperability considerations:
> 
> Published specification:
> 3GPP TS 26.234, Release 6.
> Open Mobile Alliance DRM Content Format V2.0
> 
> Applications which use this media type:
>     Third Generation Partnership Project (3GPP) Packet-switched
>         Streaming Service (PSS) clients and servers, which supports the
>         Open Mobile Alliance's specification of Digital Rights
>         Management version 2.0.
> 
> Additional information:
> 
> Magic number(s): N/A
> File extension(s): N/A
> Macintosh File Type Code(s): N/A
> 
> Person & email address to contact for further information:
>     [email-masked]
> 
> Intended usage:
> Common
> 
> Author/Change controller:
> 
> 3GPP TSG SA
> 
> ---- End of template ---
> 
> Hope for comments within a week. Otherwise any changes within 3GPP will 
> be more difficult.
> 
> Thanks
> 
> Magnus Westerlund
> 
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> 

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
>From [email-masked]  Fri Aug 13 16:06:41 2004
From: LMM at acm.org (Larry Masinter)
Date: Fri Aug 13 16:12:08 2004
Subject: Pre review of 3GPP MIME type for RTP payload format
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> MIME media type name: audio, video, text, application, image

'application' alone makes more sense than registering any
of the rest.

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Tue Jan  3 16:22:45 2006
Subject: Pre review of 3GPP MIME type for RTP payload format
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

We have detected a copy and paste error of the complete Appendix K in 
the first of the below references, and it has been replaced with the 
following version.

http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_32/Docs/S4-040481.zip

Cheers

Magnus

Magnus Westerlund wrote:

> Hi,
> 
> I would like to have a pre registration request review of the below 
> propsed MIME type for a RTP payload format. This registration request is 
> intended to use the updated registration procedure based on 
> specification available from other standards body.
> 
> The specification that the registration belongs to can be found in the 
> following 3GPP contribution:
> 
> http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_32/Docs/S4-040460.zip
> Which is the specification delta that included the RTP payload format 
> defined within to the following specification:
> 
> http://www.3gpp.org/ftp/Specs/latest/Rel-6/26_series/26234-600.zip
> 
> The registration template for this looks like the following:
> ------------------------------------------------------------
> 
> MIME media type name: audio, video, text, application, image
> 
> MIME subtype name: rtp.enc.aescm128
> 
> Required parameters:
> 
> opt:     The payload type number of the payload type contained in the
>         encrypted payload. An integer value between 0-127.
> 
> rate:     The timestamp rate of this payload type, which shall be the same
>         as that of the original payload type. This is an integer value
>         between 1 and 2^32.
> 
> ContentID: The OMA DRM content ID [75] used to identify the content when
>         establishing a crypto context. The value is an RFC 2396 [60]
>         URI, which shall be quoted using <">.
> 
> RightsIssuerURL: The right issuer URL as defined by OMA DRM [75]. The
>         value is an URI in accordance with RFC 2396 [60], which shall be
>         quoted using <">.
> 
> IVnonce: The value of this parameter is the nonce that forms the IV as
>         specified by the crypto transform, encoded using Base 64 [69].
> 
> Optional parameters:
> 
> SelectiveEncryption:     Indicates if this stream is selectively
>         encrypted. Allowed values are 0 (false) and 1 (true). If not
>         present, selective encryption shall not be used. Please note
>         that unless this indicator is integrity protected, it fulfils no
>         purpose.
> 
> Encoding considerations:
>         This type is only defined for transfer via RTP (RFC 3550).
> 
> Security considerations:
> 
> See considerations raised in RTP RFC 3550 [9] and any applicable
> profile like RFC 3551 [10] or RFC 3711 [72]. Further see 3GPP TS
> 26.234, Release 6, Annex K for comments on security issues. The main
> issues that exists are:
> 
> - This RTP payload format only confidentiality protects the RTP payload, 
> thus header information is leaked, similarly to SRTP.
> 
> - The use of stream ciphers as AES CM and no integrity protection allows 
> an attacker to purposefully attack the content of the encrypted RTP 
> payload by switching individual bits.
> 
> - The usage of selective encryption without integrity protection allows 
> for an attacker to perform any replacements of complete RTP payloads and 
> packets it desires.
> 
> - The payload format makes the receiver vulnerable to denial of service 
> attacks that inserts RTP packets into the stream, that the receiver then 
> interprets as being encrypted thus wasting computational resources. To 
> prevent this attack, authentication needs to be used.
> Interoperability considerations:
> 
> Published specification:
> 3GPP TS 26.234, Release 6.
> Open Mobile Alliance DRM Content Format V2.0
> 
> Applications which use this media type:
>     Third Generation Partnership Project (3GPP) Packet-switched
>         Streaming Service (PSS) clients and servers, which supports the
>         Open Mobile Alliance's specification of Digital Rights
>         Management version 2.0.
> 
> Additional information:
> 
> Magic number(s): N/A
> File extension(s): N/A
> Macintosh File Type Code(s): N/A
> 
> Person & email address to contact for further information:
>     [email-masked]
> 
> Intended usage:
> Common
> 
> Author/Change controller:
> 
> 3GPP TSG SA
> 
> ---- End of template ---
> 
> Hope for comments within a week. Otherwise any changes within 3GPP will 
> be more difficult.
> 
> Thanks
> 
> Magnus Westerlund
> 
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> 

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

From: csp at csperkins.org (Colin Perkins)
Date: Fri Aug 13 12:23:02 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMedia Types)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 12 Aug 2004, at 17:30, Jose Rey wrote:
> Dave, Magnus
>
> --cut--
>>>
>>> As I said in my previous email, registering under 'text' top level 
>>> type would mean that the modifiers cannot be used.
>>
>> why is that true?  does text/* only admit of plain text?  so, for
>> example, text/html would not be permitted either??
>>
>
> This is what I understand from the slides from Colin presented during 
> the
> meeting (see in http://www.dcs.gla.ac.uk/~csp/IETF60-AVT-Tue.zip,
> "09-RTP-Media-Types.pdf"). Specially slide three where it says:
>
> ". In particular, it is expected that text media types are "to some
> extent readable even without the software that interprets them"
> - RFC 2046
> - This rule is derived from email client behaviour; want to pass the 
> message
> to a dumb pager if there's no better display option"
>
> Colin or Magnus may please correct me if I got it wrong...

The slides you quote are my interpretation of the traditional rules for 
media under the "text" top level type. As you know, there has been some 
discussion on relaxing these rules for media types with limited domain 
of applicability. The RTP Payload Format for 3GPP timed text might fall 
into this new category. Accordingly, we have this MIME review to decide 
if the format should be "text" or "video".

-- 
Colin Perkins
http://csperkins.org/

From: csp at csperkins.org (Colin Perkins)
Date: Tue Jan  3 16:22:45 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMedia Types)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 12 Aug 2004, at 17:30, Jose Rey wrote:
> Dave, Magnus
>
> --cut--
>>>
>>> As I said in my previous email, registering under 'text' top level 
>>> type would mean that the modifiers cannot be used.
>>
>> why is that true?  does text/* only admit of plain text?  so, for
>> example, text/html would not be permitted either??
>>
>
> This is what I understand from the slides from Colin presented during 
> the
> meeting (see in http://www.dcs.gla.ac.uk/~csp/IETF60-AVT-Tue.zip,
> "09-RTP-Media-Types.pdf"). Specially slide three where it says:
>
> ". In particular, it is expected that text media types are "to some
> extent readable even without the software that interprets them"
> - RFC 2046
> - This rule is derived from email client behaviour; want to pass the 
> message
> to a dumb pager if there's no better display option"
>
> Colin or Magnus may please correct me if I got it wrong...

The slides you quote are my interpretation of the traditional rules for 
media under the "text" top level type. As you know, there has been some 
discussion on relaxing these rules for media types with limited domain 
of applicability. The RTP Payload Format for 3GPP timed text might fall 
into this new category. Accordingly, we have this MIME review to decide 
if the format should be "text" or "video".

-- 
Colin Perkins
http://csperkins.org/

From: rey at panasonic.de (Jose Rey)
Date: Tue Jan  3 16:22:47 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMedia Types)
In-Reply-To: <p06100557bd4149f2e984@[17.202.35.52]>
Message-ID: <[email-masked]>

Dave, Magnus

--cut--
> >
> >As I said in my previous email, registering under 'text' top level type
> >would mean that the modifiers cannot be used.
>
> why is that true?  does text/* only admit of plain text?  so, for
> example, text/html would not be permitted either??
>

This is what I understand from the slides from Colin presented during the
meeting (see in http://www.dcs.gla.ac.uk/~csp/IETF60-AVT-Tue.zip,
"09-RTP-Media-Types.pdf"). Specially slide three where it says:

". In particular, it is expected that text media types are "to some
extent readable even without the software that interprets them"
- RFC 2046
- This rule is derived from email client behaviour; want to pass the message
to a dumb pager if there's no better display option"

Colin or Magnus may please correct me if I got it wrong...

Jose

> >Hence, we can differentiate
> >between applications that could make use of text w/o or w/
> modifiers to help
> >in the decision:
> >
> >also useful w/o modifiers (would be OK to use text/3gpp-tt)
> >====================
> >- captions (in most cases)
> >- instant messaging (?)
> >- timed text conversation (? )
> >
> >only useful w/ modifiers (only makes sense with video/3gpp-tt)
> >========================
> >- commercial banners (decorated)
> >- news tickers (decorated)
> >- karaoke
> >- clickable text strings
> >- some captions (e.g. scrolling end actors' list)
> >
> >Leaving aside that most captions could be useful w/o modifiers,
> the usage of
> >timed text for the 'text' type applications like instant
> messaging or text
> >conversation seems not very probable.  There are already simpler
> codecs and
> >payload formats to do this.   The whole set of features of timed text are
> >only available if the video/3gpp-tt is used... So maybe it is more
> >appropriate to register just under 'video'?
> >
> >What about interop? Would it still be a problem if we register both?
> >
> >Thanks,
> >
> >Jose
> >
> >-cut-
>
>
> --
> David Singer
> Apple Computer/QuickTime
>

From: singer at apple.com (Dave Singer)
Date: Thu Sep 16 09:16:50 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMedia  Types)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <p06100557bd4149f2e984@[17.202.35.52]>

At 11:39 AM +0200 8/12/04, Jose Rey wrote:
>Dave, Magnus,
>
>inline...
>>  -----Original Message-----
>>  From: [email-masked] [mailto:[email-masked]]On Behalf Of
>>  Dave Singer
>>  Sent: Tuesday, August 10, 2004 7:11 PM
>>  To: Magnus Westerlund; [email-masked]'
>>  Cc: IETF AVT WG
>>  Subject: Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
>>  andMedia Types)
>>
>>
>>  At 5:55 PM +0200 8/9/04, Magnus Westerlund wrote:
>>  >Hi,
>>  >
>>  >As the RTP payload format is developed in IETF, rather than 3GPP I
>>  >think the MIME type used to identify that RTP payload format belongs
>>  >in the IETF tree. Especially as the vendor tree implies that the
>>  >3GPP has control over the registration and any updates, which I
>>  >don't think is appropriate for this payload format.
>>  >
>>  >The question is if 3GPP timed text should be registered in video,
>>  >text, or both. My reasoning behind actually registering in both
>>  >media types, would if one had clear indications that both are
>>  >appropriate for different usages of the RTP payload format.
>>
>>  I think both is the worst choice;  it's asking for interop
>>  problems, isn't it?
>>
>
>As I said in my previous email, registering under 'text' top level type
>would mean that the modifiers cannot be used.

why is that true?  does text/* only admit of plain text?  so, for 
example, text/html would not be permitted either??

>Hence, we can differentiate
>between applications that could make use of text w/o or w/ modifiers to help
>in the decision:
>
>also useful w/o modifiers (would be OK to use text/3gpp-tt)
>====================
>- captions (in most cases)
>- instant messaging (?)
>- timed text conversation (? )
>
>only useful w/ modifiers (only makes sense with video/3gpp-tt)
>========================
>- commercial banners (decorated)
>- news tickers (decorated)
>- karaoke
>- clickable text strings
>- some captions (e.g. scrolling end actors' list)
>
>Leaving aside that most captions could be useful w/o modifiers, the usage of
>timed text for the 'text' type applications like instant messaging or text
>conversation seems not very probable.  There are already simpler codecs and
>payload formats to do this.   The whole set of features of timed text are
>only available if the video/3gpp-tt is used... So maybe it is more
>appropriate to register just under 'video'?
>
>What about interop? Would it still be a problem if we register both?
>
>Thanks,
>
>Jose
>
>-cut-

-- 
David Singer
Apple Computer/QuickTime
>From [email-masked]  Thu Aug 12 18:30:50 2004
From: rey at panasonic.de (Jose Rey)
Date: Thu Sep 16 09:16:53 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
	andMedia Types)
In-Reply-To: <p06100557bd4149f2e984@[17.202.35.52]>
Message-ID: <[email-masked]>

Dave, Magnus

--cut--
> >
> >As I said in my previous email, registering under 'text' top level type
> >would mean that the modifiers cannot be used.
>
> why is that true?  does text/* only admit of plain text?  so, for
> example, text/html would not be permitted either??
>

This is what I understand from the slides from Colin presented during the
meeting (see in http://www.dcs.gla.ac.uk/~csp/IETF60-AVT-Tue.zip,
"09-RTP-Media-Types.pdf"). Specially slide three where it says:

". In particular, it is expected that text media types are "to some
extent readable even without the software that interprets them"
- RFC 2046
- This rule is derived from email client behaviour; want to pass the message
to a dumb pager if there's no better display option"

Colin or Magnus may please correct me if I got it wrong...

Jose

> >Hence, we can differentiate
> >between applications that could make use of text w/o or w/
> modifiers to help
> >in the decision:
> >
> >also useful w/o modifiers (would be OK to use text/3gpp-tt)
> >====================
> >- captions (in most cases)
> >- instant messaging (?)
> >- timed text conversation (? )
> >
> >only useful w/ modifiers (only makes sense with video/3gpp-tt)
> >========================
> >- commercial banners (decorated)
> >- news tickers (decorated)
> >- karaoke
> >- clickable text strings
> >- some captions (e.g. scrolling end actors' list)
> >
> >Leaving aside that most captions could be useful w/o modifiers,
> the usage of
> >timed text for the 'text' type applications like instant
> messaging or text
> >conversation seems not very probable.  There are already simpler
> codecs and
> >payload formats to do this.   The whole set of features of timed text are
> >only available if the video/3gpp-tt is used... So maybe it is more
> >appropriate to register just under 'video'?
> >
> >What about interop? Would it still be a problem if we register both?
> >
> >Thanks,
> >
> >Jose
> >
> >-cut-
>
>
> --
> David Singer
> Apple Computer/QuickTime
>

From: singer at apple.com (Dave Singer)
Date: Tue Jan  3 16:22:47 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMedia  Types)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <p06100557bd4149f2e984@[17.202.35.52]>

At 11:39 AM +0200 8/12/04, Jose Rey wrote:
>Dave, Magnus,
>
>inline...
>>  -----Original Message-----
>>  From: [email-masked] [mailto:[email-masked]]On Behalf Of
>>  Dave Singer
>>  Sent: Tuesday, August 10, 2004 7:11 PM
>>  To: Magnus Westerlund; [email-masked]'
>>  Cc: IETF AVT WG
>>  Subject: Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
>>  andMedia Types)
>>
>>
>>  At 5:55 PM +0200 8/9/04, Magnus Westerlund wrote:
>>  >Hi,
>>  >
>>  >As the RTP payload format is developed in IETF, rather than 3GPP I
>>  >think the MIME type used to identify that RTP payload format belongs
>>  >in the IETF tree. Especially as the vendor tree implies that the
>>  >3GPP has control over the registration and any updates, which I
>>  >don't think is appropriate for this payload format.
>>  >
>>  >The question is if 3GPP timed text should be registered in video,
>>  >text, or both. My reasoning behind actually registering in both
>>  >media types, would if one had clear indications that both are
>>  >appropriate for different usages of the RTP payload format.
>>
>>  I think both is the worst choice;  it's asking for interop
>>  problems, isn't it?
>>
>
>As I said in my previous email, registering under 'text' top level type
>would mean that the modifiers cannot be used.

why is that true?  does text/* only admit of plain text?  so, for 
example, text/html would not be permitted either??

>Hence, we can differentiate
>between applications that could make use of text w/o or w/ modifiers to help
>in the decision:
>
>also useful w/o modifiers (would be OK to use text/3gpp-tt)
>====================
>- captions (in most cases)
>- instant messaging (?)
>- timed text conversation (? )
>
>only useful w/ modifiers (only makes sense with video/3gpp-tt)
>========================
>- commercial banners (decorated)
>- news tickers (decorated)
>- karaoke
>- clickable text strings
>- some captions (e.g. scrolling end actors' list)
>
>Leaving aside that most captions could be useful w/o modifiers, the usage of
>timed text for the 'text' type applications like instant messaging or text
>conversation seems not very probable.  There are already simpler codecs and
>payload formats to do this.   The whole set of features of timed text are
>only available if the video/3gpp-tt is used... So maybe it is more
>appropriate to register just under 'video'?
>
>What about interop? Would it still be a problem if we register both?
>
>Thanks,
>
>Jose
>
>-cut-

-- 
David Singer
Apple Computer/QuickTime

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Thu Aug 12 14:45:41 2004
Subject: Pre review of 3GPP MIME type for RTP payload format
Message-ID: <[email-masked]>

Hi,

I would like to have a pre registration request review of the below 
propsed MIME type for a RTP payload format. This registration request is 
intended to use the updated registration procedure based on 
specification available from other standards body.

The specification that the registration belongs to can be found in the 
following 3GPP contribution:

http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_32/Docs/S4-040460.zip
Which is the specification delta that included the RTP payload format 
defined within to the following specification:

http://www.3gpp.org/ftp/Specs/latest/Rel-6/26_series/26234-600.zip

The registration template for this looks like the following:
------------------------------------------------------------

MIME media type name: audio, video, text, application, image

MIME subtype name: rtp.enc.aescm128

Required parameters:

opt: 	The payload type number of the payload type contained in the
         encrypted payload. An integer value between 0-127.

rate: 	The timestamp rate of this payload type, which shall be the same
         as that of the original payload type. This is an integer value
         between 1 and 2^32.

ContentID: The OMA DRM content ID [75] used to identify the content when
         establishing a crypto context. The value is an RFC 2396 [60]
         URI, which shall be quoted using <">.

RightsIssuerURL: The right issuer URL as defined by OMA DRM [75]. The
         value is an URI in accordance with RFC 2396 [60], which shall be
         quoted using <">.

IVnonce: The value of this parameter is the nonce that forms the IV as
         specified by the crypto transform, encoded using Base 64 [69].

Optional parameters:

SelectiveEncryption: 	Indicates if this stream is selectively
         encrypted. Allowed values are 0 (false) and 1 (true). If not
         present, selective encryption shall not be used. Please note
         that unless this indicator is integrity protected, it fulfils no
         purpose.

Encoding considerations:
         This type is only defined for transfer via RTP (RFC 3550).

Security considerations:

See considerations raised in RTP RFC 3550 [9] and any applicable
profile like RFC 3551 [10] or RFC 3711 [72]. Further see 3GPP TS
26.234, Release 6, Annex K for comments on security issues. The main
issues that exists are:

- This RTP payload format only confidentiality protects the RTP payload, 
thus header information is leaked, similarly to SRTP.

- The use of stream ciphers as AES CM and no integrity protection allows 
an attacker to purposefully attack the content of the encrypted RTP 
payload by switching individual bits.

- The usage of selective encryption without integrity protection allows 
for an attacker to perform any replacements of complete RTP payloads and 
packets it desires.

- The payload format makes the receiver vulnerable to denial of service 
attacks that inserts RTP packets into the stream, that the receiver then 
interprets as being encrypted thus wasting computational resources. To 
prevent this attack, authentication needs to be used.
Interoperability considerations:

Published specification:
3GPP TS 26.234, Release 6.
Open Mobile Alliance DRM Content Format V2.0

Applications which use this media type:
	Third Generation Partnership Project (3GPP) Packet-switched
         Streaming Service (PSS) clients and servers, which supports the
         Open Mobile Alliance's specification of Digital Rights
         Management version 2.0.

Additional information:

Magic number(s): N/A
File extension(s): N/A
Macintosh File Type Code(s): N/A

Person & email address to contact for further information:
	[email-masked]

Intended usage:
Common

Author/Change controller:

3GPP TSG SA

---- End of template ---

Hope for comments within a week. Otherwise any changes within 3GPP will 
be more difficult.

Thanks

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Tue Jan  3 16:22:45 2006
Subject: Pre review of 3GPP MIME type for RTP payload format
Message-ID: <[email-masked]>

Hi,

I would like to have a pre registration request review of the below 
propsed MIME type for a RTP payload format. This registration request is 
intended to use the updated registration procedure based on 
specification available from other standards body.

The specification that the registration belongs to can be found in the 
following 3GPP contribution:

http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_32/Docs/S4-040460.zip
Which is the specification delta that included the RTP payload format 
defined within to the following specification:

http://www.3gpp.org/ftp/Specs/latest/Rel-6/26_series/26234-600.zip

The registration template for this looks like the following:
------------------------------------------------------------

MIME media type name: audio, video, text, application, image

MIME subtype name: rtp.enc.aescm128

Required parameters:

opt: 	The payload type number of the payload type contained in the
         encrypted payload. An integer value between 0-127.

rate: 	The timestamp rate of this payload type, which shall be the same
         as that of the original payload type. This is an integer value
         between 1 and 2^32.

ContentID: The OMA DRM content ID [75] used to identify the content when
         establishing a crypto context. The value is an RFC 2396 [60]
         URI, which shall be quoted using <">.

RightsIssuerURL: The right issuer URL as defined by OMA DRM [75]. The
         value is an URI in accordance with RFC 2396 [60], which shall be
         quoted using <">.

IVnonce: The value of this parameter is the nonce that forms the IV as
         specified by the crypto transform, encoded using Base 64 [69].

Optional parameters:

SelectiveEncryption: 	Indicates if this stream is selectively
         encrypted. Allowed values are 0 (false) and 1 (true). If not
         present, selective encryption shall not be used. Please note
         that unless this indicator is integrity protected, it fulfils no
         purpose.

Encoding considerations:
         This type is only defined for transfer via RTP (RFC 3550).

Security considerations:

See considerations raised in RTP RFC 3550 [9] and any applicable
profile like RFC 3551 [10] or RFC 3711 [72]. Further see 3GPP TS
26.234, Release 6, Annex K for comments on security issues. The main
issues that exists are:

- This RTP payload format only confidentiality protects the RTP payload, 
thus header information is leaked, similarly to SRTP.

- The use of stream ciphers as AES CM and no integrity protection allows 
an attacker to purposefully attack the content of the encrypted RTP 
payload by switching individual bits.

- The usage of selective encryption without integrity protection allows 
for an attacker to perform any replacements of complete RTP payloads and 
packets it desires.

- The payload format makes the receiver vulnerable to denial of service 
attacks that inserts RTP packets into the stream, that the receiver then 
interprets as being encrypted thus wasting computational resources. To 
prevent this attack, authentication needs to be used.
Interoperability considerations:

Published specification:
3GPP TS 26.234, Release 6.
Open Mobile Alliance DRM Content Format V2.0

Applications which use this media type:
	Third Generation Partnership Project (3GPP) Packet-switched
         Streaming Service (PSS) clients and servers, which supports the
         Open Mobile Alliance's specification of Digital Rights
         Management version 2.0.

Additional information:

Magic number(s): N/A
File extension(s): N/A
Macintosh File Type Code(s): N/A

Person & email address to contact for further information:
	[email-masked]

Intended usage:
Common

Author/Change controller:

3GPP TSG SA

---- End of template ---

Hope for comments within a week. Otherwise any changes within 3GPP will 
be more difficult.

Thanks

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

From: rey at panasonic.de (Jose Rey)
Date: Tue Jan  3 16:22:47 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMedia Types)
In-Reply-To: <p0610050fbd3eb1f50d9e@[17.202.35.52]>
Message-ID: <[email-masked]>

Dave, Magnus,

inline...
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Dave Singer
> Sent: Tuesday, August 10, 2004 7:11 PM
> To: Magnus Westerlund; [email-masked]'
> Cc: IETF AVT WG
> Subject: Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
> andMedia Types)
>
>
> At 5:55 PM +0200 8/9/04, Magnus Westerlund wrote:
> >Hi,
> >
> >As the RTP payload format is developed in IETF, rather than 3GPP I
> >think the MIME type used to identify that RTP payload format belongs
> >in the IETF tree. Especially as the vendor tree implies that the
> >3GPP has control over the registration and any updates, which I
> >don't think is appropriate for this payload format.
> >
> >The question is if 3GPP timed text should be registered in video,
> >text, or both. My reasoning behind actually registering in both
> >media types, would if one had clear indications that both are
> >appropriate for different usages of the RTP payload format.
>
> I think both is the worst choice;  it's asking for interop
> problems, isn't it?
>

As I said in my previous email, registering under 'text' top level type
would mean that the modifiers cannot be used.  Hence, we can differentiate
between applications that could make use of text w/o or w/ modifiers to help
in the decision:

also useful w/o modifiers (would be OK to use text/3gpp-tt)
====================
- captions (in most cases)
- instant messaging (?)
- timed text conversation (? )

only useful w/ modifiers (only makes sense with video/3gpp-tt)
========================
- commercial banners (decorated)
- news tickers (decorated)
- karaoke
- clickable text strings
- some captions (e.g. scrolling end actors' list)

Leaving aside that most captions could be useful w/o modifiers, the usage of
timed text for the 'text' type applications like instant messaging or text
conversation seems not very probable.  There are already simpler codecs and
payload formats to do this.   The whole set of features of timed text are
only available if the video/3gpp-tt is used... So maybe it is more
appropriate to register just under 'video'?

What about interop? Would it still be a problem if we register both?

Thanks,

Jose

-cut-

From: singer at apple.com (Dave Singer)
Date: Thu Sep 16 09:16:44 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP and Media  Types)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <p0610050fbd3eb1f50d9e@[17.202.35.52]>

At 5:55 PM +0200 8/9/04, Magnus Westerlund wrote:
>Hi,
>
>As the RTP payload format is developed in IETF, rather than 3GPP I 
>think the MIME type used to identify that RTP payload format belongs 
>in the IETF tree. Especially as the vendor tree implies that the 
>3GPP has control over the registration and any updates, which I 
>don't think is appropriate for this payload format.
>
>The question is if 3GPP timed text should be registered in video, 
>text, or both. My reasoning behind actually registering in both 
>media types, would if one had clear indications that both are 
>appropriate for different usages of the RTP payload format.

I think both is the worst choice;  it's asking for interop problems, isn't it?

>
>Cheers
>
>Magnus
>
>Colin Perkins wrote:
>
>>[Please keep the AVT list as a cc, so the authors of the draft get a copy]
>>
>>The aim here is to register the media type for use in RTP sessions, 
>>which are negotiated using SIP. Registering it under "application" 
>>or "vnd.3gpp" would complicate the signalling, and it would be 
>>preferable from our point of view to register this under "text" or 
>>"video" (as has been done with other RTP payload formats).
>>
>>That said, I'm not sure how the vnd tree works, so there may be a 
>>good reason to register it there, and then work out how to change 
>>SIP and/or SDP to make use of it.
>>
>>Colin
>>
>
>--
>
>Magnus Westerlund
>
>Multimedia Technologies, Ericsson Research EAB/TVA/A
>----------------------------------------------------------------------
>Ericsson AB                | Phone +46 8 4048287
>Torshamsgatan 23           | Fax   +46 8 7575550
>S-164 80 Stockholm, Sweden | mailto: [email-masked]
>
>_______________________________________________
>Audio/Video Transport Working Group
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/avt

-- 
David Singer
Apple Computer/QuickTime
>From [email-masked]  Thu Aug 12 11:39:59 2004
From: rey at panasonic.de (Jose Rey)
Date: Thu Sep 16 09:16:47 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
	andMedia Types)
In-Reply-To: <p0610050fbd3eb1f50d9e@[17.202.35.52]>
Message-ID: <[email-masked]>

Dave, Magnus,

inline...
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Dave Singer
> Sent: Tuesday, August 10, 2004 7:11 PM
> To: Magnus Westerlund; [email-masked]'
> Cc: IETF AVT WG
> Subject: Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
> andMedia Types)
>
>
> At 5:55 PM +0200 8/9/04, Magnus Westerlund wrote:
> >Hi,
> >
> >As the RTP payload format is developed in IETF, rather than 3GPP I
> >think the MIME type used to identify that RTP payload format belongs
> >in the IETF tree. Especially as the vendor tree implies that the
> >3GPP has control over the registration and any updates, which I
> >don't think is appropriate for this payload format.
> >
> >The question is if 3GPP timed text should be registered in video,
> >text, or both. My reasoning behind actually registering in both
> >media types, would if one had clear indications that both are
> >appropriate for different usages of the RTP payload format.
>
> I think both is the worst choice;  it's asking for interop
> problems, isn't it?
>

As I said in my previous email, registering under 'text' top level type
would mean that the modifiers cannot be used.  Hence, we can differentiate
between applications that could make use of text w/o or w/ modifiers to help
in the decision:

also useful w/o modifiers (would be OK to use text/3gpp-tt)
====================
- captions (in most cases)
- instant messaging (?)
- timed text conversation (? )

only useful w/ modifiers (only makes sense with video/3gpp-tt)
========================
- commercial banners (decorated)
- news tickers (decorated)
- karaoke
- clickable text strings
- some captions (e.g. scrolling end actors' list)

Leaving aside that most captions could be useful w/o modifiers, the usage of
timed text for the 'text' type applications like instant messaging or text
conversation seems not very probable.  There are already simpler codecs and
payload formats to do this.   The whole set of features of timed text are
only available if the video/3gpp-tt is used... So maybe it is more
appropriate to register just under 'video'?

What about interop? Would it still be a problem if we register both?

Thanks,

Jose

-cut-

From: singer at apple.com (Dave Singer)
Date: Tue Jan  3 16:22:47 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP and Media  Types)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <p0610050fbd3eb1f50d9e@[17.202.35.52]>

At 5:55 PM +0200 8/9/04, Magnus Westerlund wrote:
>Hi,
>
>As the RTP payload format is developed in IETF, rather than 3GPP I 
>think the MIME type used to identify that RTP payload format belongs 
>in the IETF tree. Especially as the vendor tree implies that the 
>3GPP has control over the registration and any updates, which I 
>don't think is appropriate for this payload format.
>
>The question is if 3GPP timed text should be registered in video, 
>text, or both. My reasoning behind actually registering in both 
>media types, would if one had clear indications that both are 
>appropriate for different usages of the RTP payload format.

I think both is the worst choice;  it's asking for interop problems, isn't it?

>
>Cheers
>
>Magnus
>
>Colin Perkins wrote:
>
>>[Please keep the AVT list as a cc, so the authors of the draft get a copy]
>>
>>The aim here is to register the media type for use in RTP sessions, 
>>which are negotiated using SIP. Registering it under "application" 
>>or "vnd.3gpp" would complicate the signalling, and it would be 
>>preferable from our point of view to register this under "text" or 
>>"video" (as has been done with other RTP payload formats).
>>
>>That said, I'm not sure how the vnd tree works, so there may be a 
>>good reason to register it there, and then work out how to change 
>>SIP and/or SDP to make use of it.
>>
>>Colin
>>
>
>--
>
>Magnus Westerlund
>
>Multimedia Technologies, Ericsson Research EAB/TVA/A
>----------------------------------------------------------------------
>Ericsson AB                | Phone +46 8 4048287
>Torshamsgatan 23           | Fax   +46 8 7575550
>S-164 80 Stockholm, Sweden | mailto: [email-masked]
>
>_______________________________________________
>Audio/Video Transport Working Group
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/avt

-- 
David Singer
Apple Computer/QuickTime

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:45 2006
Subject: draft-hoschka-smil-media-type-12.txt
Message-ID: <[email-masked]>

I think the document should explain why it is that it registers
both application/smil and application/smil+xml with exactly
the same meaning.

I think the answer is likely that this was a mistake, that
application/smil+xml is recommended, but that 'application/smil'
is in use in some parts of the community already, and it was
thought better to register it as a valid alias.
But I'm not sure; I'm not even sure it's a good idea
to do this.  Perhaps we want to separate out 'recommended'
practice (as you would find in an IESG approved document
or a W3C 'Recommendation') from some other kind of registration,
e.g., ask IANA to register 'application/smil' with a notation
"MIME type used for what is officially registered as
application/smil+xml'.

> The definition is based on RFC3023 defining the use of the
>   "application/xml" media type [3]. Before using the "application/smil"
>   or "application/smil+xml" media type, implementors must thus be
>   familiar with [3].

As far as I can tell, [3] has nothing to say about 'application/smil'.

>   This parameter is meant to be used in MIME media type based content
>   negotiation (such as that done with the HTTP "Accept" header) to
>   negotiate for a variety of SMIL based languages. It is modelled after
>   the "profile" parameter in the application/xhtml+smil MIME type
>   registration [4], and is motivated by very similar considerations.

Presumably you mean xhtml+xml, not xhtml+smil.  Is there any
positive experience using media type parameters in content 
negotiation, in general, or in particular with "profile" with
xhtml+xml, and not using, say, media features?

> It is suggested that the "profile" parameter be
> used until the CC/PP protocol work has been finalized.

By whom would this parameter be used?

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Thu Sep 16 09:16:41 2004
Subject: Registration for application/gdiff
Message-ID: <[email-masked]>

I'm trying to register a MIME type officially for application/gdiff.  
This type was defined in a W3C NOTE several years ago:

<http://www.w3.org/TR/NOTE-gdiff-19970901>

That Note defines the MIME type but apparently the authors never 
registered the MIME type with IANA.  Now we'd like to use gdiff in 
applications where we'd be using the MIME type so having it officially 
registered would be nice.   For example:

<http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-03.txt> 
  (try -04 if -03 turns up not found)

I submitted the registration through the IANA web form a couple weeks 
ago but haven't gotten a response other than the automated form 
submission response.  Is this smoothly underway or is there anything 
else I need to or can optionally do to help this registration out?

Thanks,

Lisa

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Tue Jan  3 16:22:47 2006
Subject: Registration for application/gdiff
Message-ID: <[email-masked]>

I'm trying to register a MIME type officially for application/gdiff.  
This type was defined in a W3C NOTE several years ago:

<http://www.w3.org/TR/NOTE-gdiff-19970901>

That Note defines the MIME type but apparently the authors never 
registered the MIME type with IANA.  Now we'd like to use gdiff in 
applications where we'd be using the MIME type so having it officially 
registered would be nice.   For example:

<http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-03.txt> 
  (try -04 if -03 turns up not found)

I submitted the registration through the IANA web form a couple weeks 
ago but haven't gotten a response other than the automated form 
submission response.  Is this smoothly underway or is there anything 
else I need to or can optionally do to help this registration out?

Thanks,

Lisa

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Mon Aug  9 17:56:05 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP and Media Types)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

As the RTP payload format is developed in IETF, rather than 3GPP I think 
the MIME type used to identify that RTP payload format belongs in the 
IETF tree. Especially as the vendor tree implies that the 3GPP has 
control over the registration and any updates, which I don't think is 
appropriate for this payload format.

The question is if 3GPP timed text should be registered in video, text, 
or both. My reasoning behind actually registering in both media types, 
would if one had clear indications that both are appropriate for 
different usages of the RTP payload format.

Cheers

Magnus

Colin Perkins wrote:

> [Please keep the AVT list as a cc, so the authors of the draft get a copy]
> 
> The aim here is to register the media type for use in RTP sessions, 
> which are negotiated using SIP. Registering it under "application" or 
> "vnd.3gpp" would complicate the signalling, and it would be preferable 
> from our point of view to register this under "text" or "video" (as has 
> been done with other RTP payload formats).
> 
> That said, I'm not sure how the vnd tree works, so there may be a good 
> reason to register it there, and then work out how to change SIP and/or 
> SDP to make use of it.
> 
> Colin
> 
> 

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
>From [email-masked]  Mon Aug  9 22:08:24 2004
From: LMM at acm.org (Larry Masinter)
Date: Mon Aug  9 22:08:32 2004
Subject: draft-hoschka-smil-media-type-12.txt
Message-ID: <[email-masked]>

I think the document should explain why it is that it registers
both application/smil and application/smil+xml with exactly
the same meaning.

I think the answer is likely that this was a mistake, that
application/smil+xml is recommended, but that 'application/smil'
is in use in some parts of the community already, and it was
thought better to register it as a valid alias.
But I'm not sure; I'm not even sure it's a good idea
to do this.  Perhaps we want to separate out 'recommended'
practice (as you would find in an IESG approved document
or a W3C 'Recommendation') from some other kind of registration,
e.g., ask IANA to register 'application/smil' with a notation
"MIME type used for what is officially registered as
application/smil+xml'.

> The definition is based on RFC3023 defining the use of the
>   "application/xml" media type [3]. Before using the "application/smil"
>   or "application/smil+xml" media type, implementors must thus be
>   familiar with [3].

As far as I can tell, [3] has nothing to say about 'application/smil'.

>   This parameter is meant to be used in MIME media type based content
>   negotiation (such as that done with the HTTP "Accept" header) to
>   negotiate for a variety of SMIL based languages. It is modelled after
>   the "profile" parameter in the application/xhtml+smil MIME type
>   registration [4], and is motivated by very similar considerations.

Presumably you mean xhtml+xml, not xhtml+smil.  Is there any
positive experience using media type parameters in content 
negotiation, in general, or in particular with "profile" with
xhtml+xml, and not using, say, media features?

> It is suggested that the "profile" parameter be
> used until the CC/PP protocol work has been finalized.

By whom would this parameter be used?

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Tue Jan  3 16:22:45 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP and Media Types)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

As the RTP payload format is developed in IETF, rather than 3GPP I think 
the MIME type used to identify that RTP payload format belongs in the 
IETF tree. Especially as the vendor tree implies that the 3GPP has 
control over the registration and any updates, which I don't think is 
appropriate for this payload format.

The question is if 3GPP timed text should be registered in video, text, 
or both. My reasoning behind actually registering in both media types, 
would if one had clear indications that both are appropriate for 
different usages of the RTP payload format.

Cheers

Magnus

Colin Perkins wrote:

> [Please keep the AVT list as a cc, so the authors of the draft get a copy]
> 
> The aim here is to register the media type for use in RTP sessions, 
> which are negotiated using SIP. Registering it under "application" or 
> "vnd.3gpp" would complicate the signalling, and it would be preferable 
> from our point of view to register this under "text" or "video" (as has 
> been done with other RTP payload formats).
> 
> That said, I'm not sure how the vnd tree works, so there may be a good 
> reason to register it there, and then work out how to change SIP and/or 
> SDP to make use of it.
> 
> Colin
> 
> 

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

From: csp at csperkins.org (Colin Perkins)
Date: Tue Jan  3 16:22:45 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP and Media Types)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

[Please keep the AVT list as a cc, so the authors of the draft get a 
copy]

The aim here is to register the media type for use in RTP sessions, 
which are negotiated using SIP. Registering it under "application" or 
"vnd.3gpp" would complicate the signalling, and it would be preferable 
from our point of view to register this under "text" or "video" (as has 
been done with other RTP payload formats).

That said, I'm not sure how the vnd tree works, so there may be a good 
reason to register it there, and then work out how to change SIP and/or 
SDP to make use of it.

Colin

On 9 Aug 2004, at 16:28, Biot Olivier wrote:
> How about registering it in the "application" tree, under "vnd.3gpp"?
> You will already find some 3GPP registrations there.
>
> See for instance:
> http://www.iana.org/assignments/media-types/application/
>
> Best regards,
>
> Olivier
>
> |-----Original Message-----
> |From: Colin Perkins
> |
> |
> |I'm forwarding this question to the IETF-types list since I'm not sure
> |we have the experience to decide this in the AVT working grou. The
> |question is about draft-ietf-avt-rtp-3gpp-timed-text-04.txt: is it
> |appropriate to register the format under the "video" or "text"
> |top-level type?
> |
> |Colin
> |
> |
> |
> |Begin forwarded message:
> |
> |> From: "Jose Rey"
> |>
> |> Colin, Magnus, all,
> |>
> |> I would like to take the opportunity to make a call for comments on
> |> whether to registrate the 3GPP timed text payload format also under
> |> the "text" top level type.  Two observations:
> |>
> |> In the 3GPP Timed text format, the text strings in the
> |payload itself
> |> are encoded using UTF8 or UTF 16, which should be a sufficiently low
> |> requirement.  Of course, all the decoration and nice
> |features such as
> |> font/background color, scroll, hyperlinks, blinking text is lost.
> |> Since the main target of timed text is exactly applications that do
> |> need this, the question is whether it makes sense to do
> |this.  Please
> |> comment.
> |>
> |> A different issue that addresses another comment from Colin below is
> |> the fact that timed text is currently used for download
> |using HTTP in
> |> 3GPP unicast streaming service.  So it is used in another domain.
> |> However, no MIME type is defined there but just an identifier
> |> "Timed-Text", how should this be synchronised?
> |>
> |>
> |> Thanks,
> |>
> |> Jose
> |>
> |>> -----Original Message-----
> |>> From: Colin Perkins
> |>>
> |>>
> |>> Folks,
> |>>
> |>> The working group recently sent the registration for the text/red
> |>> media
> |>> type <draft-ietf-avt-text-red-05.txt> to the IESG for
> |publication as a
> |>> Proposed Standard RFC. The IESG asked for expert review of
> |the draft
> |>> by
> |>> MIME experts (as is normal for media type registrations). The
> |>> reviewers
> |>> found a number of problems with the draft, and these issues
> |>> potentially
> |>> affect all other RTP payload types.
> |>>
> |>> It was noted that the rules for registering media types under the
> |>> "text" top level type are stricter than those for audio and video
> |>> types. In particular, it is expected that text media types are, to
> |>> some
> |>> extent,
> |>> readable even without the software that interprets them [RFC 2046].
> |>> This rule is derived from email client behaviour, where one wants 
> to
> |>> pass the message to a dumb pager if there is no better
> |display option,
> |>> and have something reasonable happen.
> |>>
> |>> This is clearly not the case for the "text/red" or "text/parityfec"
> |>> media types, which are error correcting codes sent over a stream of
> |>> unreliable datagrams, and require complex processing at the 
> receiver
> |>> before text can be recovered.  The "text/t140" format is arguably
> |>> justified since packets contain plain text in UTF-8 format,
> |and can be
> |>> directly displayed once they have been received.
> |>>
> |>> The discussion of our use of the "text" top level type led
> |to a review
> |>> of our other uses of media types with RTP. It was noted
> |that the rules
> |>> for media type registrations don't currently allow for
> |domain specific
> |>> types: it is not legal to register a media type saying "this type 
> is
> |>> defined only for use over RTP". This conflicts with the rules in 
> RFC
> |>> 3555, and affects all the media types registered for use with RTP.
> |>>
> |>> After much discussion between the chairs, area directors, and MIME
> |>> experts, it was concluded that is it appropriate to relax the rules
> |>> for
> |>> media type registrations in two ways:
> |>>
> |>>   - Allow domain specific media type registrations
> |>>
> |>>   - Allow complex text formats, provided they have restricted 
> domain
> |>>     of applicability and do not affect backwards compatibility for
> |>>     email clients
> |>>
> |>> This change will be discussed on the <[email-masked]> mailing
> |>> list.
> |>>
> |>> These updates will allow us to continue basically unchanged with 
> our
> |>> use of
> |>> media types in AVT. However, they will take time to
> |complete, since we
> |>> must update the media type registration rules for both MIME and 
> RTP.
> |>>
> |>> The immediate consequence for the AVT working group is that the
> |>> publication of draft-ietf-avt-text-red-05.txt may be
> |slightly delayed
> |>> (we do not expect any change to this draft, but it cannot
> |be published
> |>> until the MIME type registration rules have changed). In
> |addition, the
> |>> media type registration guidelines in RFC 3555 will need to be
> |>> updated.
> |>> The chairs will co-ordinate this - please contact us if you have 
> any
> |>> questions on the change.
> |>>
> |>> In future, as new RTP payload formats are developed, we will 
> require
> |>> expert
> |>> review of the media type registration as part of the working group
> |>> last
> |>> call process. Please contact the chairs for guidance on the
> |procedure
> |>> for this review, when you believe your draft is ready for working
> |>> group
> |>> last call. We will not forward drafts to the IESG for publication
> |>> unless they have received such review.
> |>>
> |>> --
> |>> Colin Perkins
> |>> http://csperkins.org/
> |>>
> |>>
> |>> _______________________________________________
> |>> Audio/Video Transport Working Group
> |>> avt at ietf.org
> |>> https://www1.ietf.org/mailman/listinfo/avt
>
>
-- 
Colin Perkins
http://csperkins.org/

From: Olivier.Biot at siemens.com (Biot Olivier)
Date: Mon Aug  9 17:28:39 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP and  Media Types)
Message-ID: <[email-masked]>

How about registering it in the "application" tree, under "vnd.3gpp"?
You will already find some 3GPP registrations there.

See for instance:
http://www.iana.org/assignments/media-types/application/

Best regards,

Olivier

|-----Original Message-----
|From: Colin Perkins
|
|
|I'm forwarding this question to the IETF-types list since I'm not sure 
|we have the experience to decide this in the AVT working grou. The 
|question is about draft-ietf-avt-rtp-3gpp-timed-text-04.txt: is it 
|appropriate to register the format under the "video" or "text" 
|top-level type?
|
|Colin
|
|
|
|Begin forwarded message:
|
|> From: "Jose Rey"
|>
|> Colin, Magnus, all,
|>
|> I would like to take the opportunity to make a call for comments on 
|> whether to registrate the 3GPP timed text payload format also under 
|> the "text" top level type.  Two observations:
|>
|> In the 3GPP Timed text format, the text strings in the 
|payload itself 
|> are encoded using UTF8 or UTF 16, which should be a sufficiently low 
|> requirement.  Of course, all the decoration and nice 
|features such as 
|> font/background color, scroll, hyperlinks, blinking text is lost.  
|> Since the main target of timed text is exactly applications that do 
|> need this, the question is whether it makes sense to do 
|this.  Please 
|> comment.
|>
|> A different issue that addresses another comment from Colin below is 
|> the fact that timed text is currently used for download 
|using HTTP in 
|> 3GPP unicast streaming service.  So it is used in another domain. 
|> However, no MIME type is defined there but just an identifier 
|> "Timed-Text", how should this be synchronised?
|>
|>
|> Thanks,
|>
|> Jose
|>
|>> -----Original Message-----
|>> From: Colin Perkins
|>>
|>>
|>> Folks,
|>>
|>> The working group recently sent the registration for the text/red 
|>> media
|>> type <draft-ietf-avt-text-red-05.txt> to the IESG for 
|publication as a
|>> Proposed Standard RFC. The IESG asked for expert review of 
|the draft 
|>> by
|>> MIME experts (as is normal for media type registrations). The 
|>> reviewers
|>> found a number of problems with the draft, and these issues 
|>> potentially
|>> affect all other RTP payload types.
|>>
|>> It was noted that the rules for registering media types under the
|>> "text" top level type are stricter than those for audio and video
|>> types. In particular, it is expected that text media types are, to 
|>> some
|>> extent,
|>> readable even without the software that interprets them [RFC 2046].
|>> This rule is derived from email client behaviour, where one wants to
|>> pass the message to a dumb pager if there is no better 
|display option,
|>> and have something reasonable happen.
|>>
|>> This is clearly not the case for the "text/red" or "text/parityfec"
|>> media types, which are error correcting codes sent over a stream of
|>> unreliable datagrams, and require complex processing at the receiver
|>> before text can be recovered.  The "text/t140" format is arguably
|>> justified since packets contain plain text in UTF-8 format, 
|and can be
|>> directly displayed once they have been received.
|>>
|>> The discussion of our use of the "text" top level type led 
|to a review
|>> of our other uses of media types with RTP. It was noted 
|that the rules
|>> for media type registrations don't currently allow for 
|domain specific
|>> types: it is not legal to register a media type saying "this type is
|>> defined only for use over RTP". This conflicts with the rules in RFC
|>> 3555, and affects all the media types registered for use with RTP.
|>>
|>> After much discussion between the chairs, area directors, and MIME
|>> experts, it was concluded that is it appropriate to relax the rules 
|>> for
|>> media type registrations in two ways:
|>>
|>>   - Allow domain specific media type registrations
|>>
|>>   - Allow complex text formats, provided they have restricted domain
|>>     of applicability and do not affect backwards compatibility for
|>>     email clients
|>>
|>> This change will be discussed on the <[email-masked]> mailing 
|>> list.
|>>
|>> These updates will allow us to continue basically unchanged with our
|>> use of
|>> media types in AVT. However, they will take time to 
|complete, since we
|>> must update the media type registration rules for both MIME and RTP.
|>>
|>> The immediate consequence for the AVT working group is that the
|>> publication of draft-ietf-avt-text-red-05.txt may be 
|slightly delayed
|>> (we do not expect any change to this draft, but it cannot 
|be published
|>> until the MIME type registration rules have changed). In 
|addition, the
|>> media type registration guidelines in RFC 3555 will need to be 
|>> updated.
|>> The chairs will co-ordinate this - please contact us if you have any
|>> questions on the change.
|>>
|>> In future, as new RTP payload formats are developed, we will require
|>> expert
|>> review of the media type registration as part of the working group 
|>> last
|>> call process. Please contact the chairs for guidance on the 
|procedure
|>> for this review, when you believe your draft is ready for working 
|>> group
|>> last call. We will not forward drafts to the IESG for publication
|>> unless they have received such review.
|>>
|>> --
|>> Colin Perkins
|>> http://csperkins.org/
|>>
|>>
|>> _______________________________________________
|>> Audio/Video Transport Working Group
|>> avt at ietf.org
|>> https://www1.ietf.org/mailman/listinfo/avt
>From [email-masked]  Mon Aug  9 17:38:50 2004
From: csp at csperkins.org (Colin Perkins)
Date: Mon Aug  9 17:39:12 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP and
	Media Types)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

[Please keep the AVT list as a cc, so the authors of the draft get a 
copy]

The aim here is to register the media type for use in RTP sessions, 
which are negotiated using SIP. Registering it under "application" or 
"vnd.3gpp" would complicate the signalling, and it would be preferable 
from our point of view to register this under "text" or "video" (as has 
been done with other RTP payload formats).

That said, I'm not sure how the vnd tree works, so there may be a good 
reason to register it there, and then work out how to change SIP and/or 
SDP to make use of it.

Colin

On 9 Aug 2004, at 16:28, Biot Olivier wrote:
> How about registering it in the "application" tree, under "vnd.3gpp"?
> You will already find some 3GPP registrations there.
>
> See for instance:
> http://www.iana.org/assignments/media-types/application/
>
> Best regards,
>
> Olivier
>
> |-----Original Message-----
> |From: Colin Perkins
> |
> |
> |I'm forwarding this question to the IETF-types list since I'm not sure
> |we have the experience to decide this in the AVT working grou. The
> |question is about draft-ietf-avt-rtp-3gpp-timed-text-04.txt: is it
> |appropriate to register the format under the "video" or "text"
> |top-level type?
> |
> |Colin
> |
> |
> |
> |Begin forwarded message:
> |
> |> From: "Jose Rey"
> |>
> |> Colin, Magnus, all,
> |>
> |> I would like to take the opportunity to make a call for comments on
> |> whether to registrate the 3GPP timed text payload format also under
> |> the "text" top level type.  Two observations:
> |>
> |> In the 3GPP Timed text format, the text strings in the
> |payload itself
> |> are encoded using UTF8 or UTF 16, which should be a sufficiently low
> |> requirement.  Of course, all the decoration and nice
> |features such as
> |> font/background color, scroll, hyperlinks, blinking text is lost.
> |> Since the main target of timed text is exactly applications that do
> |> need this, the question is whether it makes sense to do
> |this.  Please
> |> comment.
> |>
> |> A different issue that addresses another comment from Colin below is
> |> the fact that timed text is currently used for download
> |using HTTP in
> |> 3GPP unicast streaming service.  So it is used in another domain.
> |> However, no MIME type is defined there but just an identifier
> |> "Timed-Text", how should this be synchronised?
> |>
> |>
> |> Thanks,
> |>
> |> Jose
> |>
> |>> -----Original Message-----
> |>> From: Colin Perkins
> |>>
> |>>
> |>> Folks,
> |>>
> |>> The working group recently sent the registration for the text/red
> |>> media
> |>> type <draft-ietf-avt-text-red-05.txt> to the IESG for
> |publication as a
> |>> Proposed Standard RFC. The IESG asked for expert review of
> |the draft
> |>> by
> |>> MIME experts (as is normal for media type registrations). The
> |>> reviewers
> |>> found a number of problems with the draft, and these issues
> |>> potentially
> |>> affect all other RTP payload types.
> |>>
> |>> It was noted that the rules for registering media types under the
> |>> "text" top level type are stricter than those for audio and video
> |>> types. In particular, it is expected that text media types are, to
> |>> some
> |>> extent,
> |>> readable even without the software that interprets them [RFC 2046].
> |>> This rule is derived from email client behaviour, where one wants 
> to
> |>> pass the message to a dumb pager if there is no better
> |display option,
> |>> and have something reasonable happen.
> |>>
> |>> This is clearly not the case for the "text/red" or "text/parityfec"
> |>> media types, which are error correcting codes sent over a stream of
> |>> unreliable datagrams, and require complex processing at the 
> receiver
> |>> before text can be recovered.  The "text/t140" format is arguably
> |>> justified since packets contain plain text in UTF-8 format,
> |and can be
> |>> directly displayed once they have been received.
> |>>
> |>> The discussion of our use of the "text" top level type led
> |to a review
> |>> of our other uses of media types with RTP. It was noted
> |that the rules
> |>> for media type registrations don't currently allow for
> |domain specific
> |>> types: it is not legal to register a media type saying "this type 
> is
> |>> defined only for use over RTP". This conflicts with the rules in 
> RFC
> |>> 3555, and affects all the media types registered for use with RTP.
> |>>
> |>> After much discussion between the chairs, area directors, and MIME
> |>> experts, it was concluded that is it appropriate to relax the rules
> |>> for
> |>> media type registrations in two ways:
> |>>
> |>>   - Allow domain specific media type registrations
> |>>
> |>>   - Allow complex text formats, provided they have restricted 
> domain
> |>>     of applicability and do not affect backwards compatibility for
> |>>     email clients
> |>>
> |>> This change will be discussed on the <[email-masked]> mailing
> |>> list.
> |>>
> |>> These updates will allow us to continue basically unchanged with 
> our
> |>> use of
> |>> media types in AVT. However, they will take time to
> |complete, since we
> |>> must update the media type registration rules for both MIME and 
> RTP.
> |>>
> |>> The immediate consequence for the AVT working group is that the
> |>> publication of draft-ietf-avt-text-red-05.txt may be
> |slightly delayed
> |>> (we do not expect any change to this draft, but it cannot
> |be published
> |>> until the MIME type registration rules have changed). In
> |addition, the
> |>> media type registration guidelines in RFC 3555 will need to be
> |>> updated.
> |>> The chairs will co-ordinate this - please contact us if you have 
> any
> |>> questions on the change.
> |>>
> |>> In future, as new RTP payload formats are developed, we will 
> require
> |>> expert
> |>> review of the media type registration as part of the working group
> |>> last
> |>> call process. Please contact the chairs for guidance on the
> |procedure
> |>> for this review, when you believe your draft is ready for working
> |>> group
> |>> last call. We will not forward drafts to the IESG for publication
> |>> unless they have received such review.
> |>>
> |>> --
> |>> Colin Perkins
> |>> http://csperkins.org/
> |>>
> |>>
> |>> _______________________________________________
> |>> Audio/Video Transport Working Group
> |>> avt at ietf.org
> |>> https://www1.ietf.org/mailman/listinfo/avt
>
>
-- 
Colin Perkins
http://csperkins.org/

From: Olivier.Biot at siemens.com (Biot Olivier)
Date: Tue Jan  3 16:22:45 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP and  Media Types)
Message-ID: <[email-masked]>

How about registering it in the "application" tree, under "vnd.3gpp"?
You will already find some 3GPP registrations there.

See for instance:
http://www.iana.org/assignments/media-types/application/

Best regards,

Olivier

|-----Original Message-----
|From: Colin Perkins
|
|
|I'm forwarding this question to the IETF-types list since I'm not sure 
|we have the experience to decide this in the AVT working grou. The 
|question is about draft-ietf-avt-rtp-3gpp-timed-text-04.txt: is it 
|appropriate to register the format under the "video" or "text" 
|top-level type?
|
|Colin
|
|
|
|Begin forwarded message:
|
|> From: "Jose Rey"
|>
|> Colin, Magnus, all,
|>
|> I would like to take the opportunity to make a call for comments on 
|> whether to registrate the 3GPP timed text payload format also under 
|> the "text" top level type.  Two observations:
|>
|> In the 3GPP Timed text format, the text strings in the 
|payload itself 
|> are encoded using UTF8 or UTF 16, which should be a sufficiently low 
|> requirement.  Of course, all the decoration and nice 
|features such as 
|> font/background color, scroll, hyperlinks, blinking text is lost.  
|> Since the main target of timed text is exactly applications that do 
|> need this, the question is whether it makes sense to do 
|this.  Please 
|> comment.
|>
|> A different issue that addresses another comment from Colin below is 
|> the fact that timed text is currently used for download 
|using HTTP in 
|> 3GPP unicast streaming service.  So it is used in another domain. 
|> However, no MIME type is defined there but just an identifier 
|> "Timed-Text", how should this be synchronised?
|>
|>
|> Thanks,
|>
|> Jose
|>
|>> -----Original Message-----
|>> From: Colin Perkins
|>>
|>>
|>> Folks,
|>>
|>> The working group recently sent the registration for the text/red 
|>> media
|>> type <draft-ietf-avt-text-red-05.txt> to the IESG for 
|publication as a
|>> Proposed Standard RFC. The IESG asked for expert review of 
|the draft 
|>> by
|>> MIME experts (as is normal for media type registrations). The 
|>> reviewers
|>> found a number of problems with the draft, and these issues 
|>> potentially
|>> affect all other RTP payload types.
|>>
|>> It was noted that the rules for registering media types under the
|>> "text" top level type are stricter than those for audio and video
|>> types. In particular, it is expected that text media types are, to 
|>> some
|>> extent,
|>> readable even without the software that interprets them [RFC 2046].
|>> This rule is derived from email client behaviour, where one wants to
|>> pass the message to a dumb pager if there is no better 
|display option,
|>> and have something reasonable happen.
|>>
|>> This is clearly not the case for the "text/red" or "text/parityfec"
|>> media types, which are error correcting codes sent over a stream of
|>> unreliable datagrams, and require complex processing at the receiver
|>> before text can be recovered.  The "text/t140" format is arguably
|>> justified since packets contain plain text in UTF-8 format, 
|and can be
|>> directly displayed once they have been received.
|>>
|>> The discussion of our use of the "text" top level type led 
|to a review
|>> of our other uses of media types with RTP. It was noted 
|that the rules
|>> for media type registrations don't currently allow for 
|domain specific
|>> types: it is not legal to register a media type saying "this type is
|>> defined only for use over RTP". This conflicts with the rules in RFC
|>> 3555, and affects all the media types registered for use with RTP.
|>>
|>> After much discussion between the chairs, area directors, and MIME
|>> experts, it was concluded that is it appropriate to relax the rules 
|>> for
|>> media type registrations in two ways:
|>>
|>>   - Allow domain specific media type registrations
|>>
|>>   - Allow complex text formats, provided they have restricted domain
|>>     of applicability and do not affect backwards compatibility for
|>>     email clients
|>>
|>> This change will be discussed on the <[email-masked]> mailing 
|>> list.
|>>
|>> These updates will allow us to continue basically unchanged with our
|>> use of
|>> media types in AVT. However, they will take time to 
|complete, since we
|>> must update the media type registration rules for both MIME and RTP.
|>>
|>> The immediate consequence for the AVT working group is that the
|>> publication of draft-ietf-avt-text-red-05.txt may be 
|slightly delayed
|>> (we do not expect any change to this draft, but it cannot 
|be published
|>> until the MIME type registration rules have changed). In 
|addition, the
|>> media type registration guidelines in RFC 3555 will need to be 
|>> updated.
|>> The chairs will co-ordinate this - please contact us if you have any
|>> questions on the change.
|>>
|>> In future, as new RTP payload formats are developed, we will require
|>> expert
|>> review of the media type registration as part of the working group 
|>> last
|>> call process. Please contact the chairs for guidance on the 
|procedure
|>> for this review, when you believe your draft is ready for working 
|>> group
|>> last call. We will not forward drafts to the IESG for publication
|>> unless they have received such review.
|>>
|>> --
|>> Colin Perkins
|>> http://csperkins.org/
|>>
|>>
|>> _______________________________________________
|>> Audio/Video Transport Working Group
|>> avt at ietf.org
|>> https://www1.ietf.org/mailman/listinfo/avt

From: csp at csperkins.org (Colin Perkins)
Date: Tue Jan  3 16:22:45 2006
Subject: Fwd: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP and Media Types)
Message-ID: <[email-masked]>

I'm forwarding this question to the IETF-types list since I'm not sure 
we have the experience to decide this in the AVT working grou. The 
question is about draft-ietf-avt-rtp-3gpp-timed-text-04.txt: is it 
appropriate to register the format under the "video" or "text" 
top-level type?

Colin

Begin forwarded message:

> From: "Jose Rey" <[email-masked]>
> Date: 5 August 2004 19:13:39 BST
> To: "Colin Perkins" <[email-masked]>, "IETF AVT WG" <[email-masked]>
> Cc: Jan van der Meer <[email-masked]>, Magnus Westerlund 
> <[email-masked]>, Dave Singer <[email-masked]>, 
> Yoshinori Matsui <[email-masked]>
> Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP and 
> Media Types)
>
> Colin, Magnus, all,
>
> I would like to take the opportunity to make a call for comments on 
> whether to registrate the 3GPP timed text payload format also under 
> the "text" top level type.  Two observations:
>
> In the 3GPP Timed text format, the text strings in the payload itself 
> are encoded using UTF8 or UTF 16, which should be a sufficiently low 
> requirement.  Of course, all the decoration and nice features such as 
> font/background color, scroll, hyperlinks, blinking text is lost.  
> Since the main target of timed text is exactly applications that do 
> need this, the question is whether it makes sense to do this.  Please 
> comment.
>
> A different issue that addresses another comment from Colin below is 
> the fact that timed text is currently used for download using HTTP in 
> 3GPP unicast streaming service.  So it is used in another domain. 
> However, no MIME type is defined there but just an identifier 
> "Timed-Text", how should this be synchronised?
>
>
> Thanks,
>
> Jose
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]On Behalf Of
>> Colin Perkins
>> Sent: Donnerstag, 5. August 2004 19:09
>> To: IETF AVT WG
>> Cc: Magnus Westerlund
>> Subject: [AVT] RTP and Media Types
>>
>>
>> Folks,
>>
>> The working group recently sent the registration for the text/red 
>> media
>> type <draft-ietf-avt-text-red-05.txt> to the IESG for publication as a
>> Proposed Standard RFC. The IESG asked for expert review of the draft 
>> by
>> MIME experts (as is normal for media type registrations). The 
>> reviewers
>> found a number of problems with the draft, and these issues 
>> potentially
>> affect all other RTP payload types.
>>
>> It was noted that the rules for registering media types under the
>> "text" top level type are stricter than those for audio and video
>> types. In particular, it is expected that text media types are, to 
>> some
>> extent,
>> readable even without the software that interprets them [RFC 2046].
>> This rule is derived from email client behaviour, where one wants to
>> pass the message to a dumb pager if there is no better display option,
>> and have something reasonable happen.
>>
>> This is clearly not the case for the "text/red" or "text/parityfec"
>> media types, which are error correcting codes sent over a stream of
>> unreliable datagrams, and require complex processing at the receiver
>> before text can be recovered.  The "text/t140" format is arguably
>> justified since packets contain plain text in UTF-8 format, and can be
>> directly displayed once they have been received.
>>
>> The discussion of our use of the "text" top level type led to a review
>> of our other uses of media types with RTP. It was noted that the rules
>> for media type registrations don't currently allow for domain specific
>> types: it is not legal to register a media type saying "this type is
>> defined only for use over RTP". This conflicts with the rules in RFC
>> 3555, and affects all the media types registered for use with RTP.
>>
>> After much discussion between the chairs, area directors, and MIME
>> experts, it was concluded that is it appropriate to relax the rules 
>> for
>> media type registrations in two ways:
>>
>>   - Allow domain specific media type registrations
>>
>>   - Allow complex text formats, provided they have restricted domain
>>     of applicability and do not affect backwards compatibility for
>>     email clients
>>
>> This change will be discussed on the <[email-masked]> mailing 
>> list.
>>
>> These updates will allow us to continue basically unchanged with our
>> use of
>> media types in AVT. However, they will take time to complete, since we
>> must update the media type registration rules for both MIME and RTP.
>>
>> The immediate consequence for the AVT working group is that the
>> publication of draft-ietf-avt-text-red-05.txt may be slightly delayed
>> (we do not expect any change to this draft, but it cannot be published
>> until the MIME type registration rules have changed). In addition, the
>> media type registration guidelines in RFC 3555 will need to be 
>> updated.
>> The chairs will co-ordinate this - please contact us if you have any
>> questions on the change.
>>
>> In future, as new RTP payload formats are developed, we will require
>> expert
>> review of the media type registration as part of the working group 
>> last
>> call process. Please contact the chairs for guidance on the procedure
>> for this review, when you believe your draft is ready for working 
>> group
>> last call. We will not forward drafts to the IESG for publication
>> unless they have received such review.
>>
>> --
>> Colin Perkins
>> http://csperkins.org/
>>
>>
>> _______________________________________________
>> Audio/Video Transport Working Group
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/avt

From: shollenbeck at verisign.com (Hollenbeck, Scott)
Date: Mon Aug  9 14:52:06 2004
Subject: MIME-type Review Request: draft-ietf-avt-rtp-dsr-codecs-03.txt
Message-ID: <[email-masked]>

This is a request for MIME-type review for this document:

http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-dsr-codecs-03.txt

Please send comments to both the ietf-types list and the cc recipients
listed on this message.

Thank you,
-Scott-
>From [email-masked]  Mon Aug  9 17:15:11 2004
From: csp at csperkins.org (Colin Perkins)
Date: Mon Aug  9 17:15:56 2004
Subject: Fwd: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP and
	Media Types)
Message-ID: <[email-masked]>

I'm forwarding this question to the IETF-types list since I'm not sure 
we have the experience to decide this in the AVT working grou. The 
question is about draft-ietf-avt-rtp-3gpp-timed-text-04.txt: is it 
appropriate to register the format under the "video" or "text" 
top-level type?

Colin

Begin forwarded message:

> From: "Jose Rey" <[email-masked]>
> Date: 5 August 2004 19:13:39 BST
> To: "Colin Perkins" <[email-masked]>, "IETF AVT WG" <[email-masked]>
> Cc: Jan van der Meer <[email-masked]>, Magnus Westerlund 
> <[email-masked]>, Dave Singer <[email-masked]>, 
> Yoshinori Matsui <[email-masked]>
> Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP and 
> Media Types)
>
> Colin, Magnus, all,
>
> I would like to take the opportunity to make a call for comments on 
> whether to registrate the 3GPP timed text payload format also under 
> the "text" top level type.  Two observations:
>
> In the 3GPP Timed text format, the text strings in the payload itself 
> are encoded using UTF8 or UTF 16, which should be a sufficiently low 
> requirement.  Of course, all the decoration and nice features such as 
> font/background color, scroll, hyperlinks, blinking text is lost.  
> Since the main target of timed text is exactly applications that do 
> need this, the question is whether it makes sense to do this.  Please 
> comment.
>
> A different issue that addresses another comment from Colin below is 
> the fact that timed text is currently used for download using HTTP in 
> 3GPP unicast streaming service.  So it is used in another domain. 
> However, no MIME type is defined there but just an identifier 
> "Timed-Text", how should this be synchronised?
>
>
> Thanks,
>
> Jose
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]On Behalf Of
>> Colin Perkins
>> Sent: Donnerstag, 5. August 2004 19:09
>> To: IETF AVT WG
>> Cc: Magnus Westerlund
>> Subject: [AVT] RTP and Media Types
>>
>>
>> Folks,
>>
>> The working group recently sent the registration for the text/red 
>> media
>> type <draft-ietf-avt-text-red-05.txt> to the IESG for publication as a
>> Proposed Standard RFC. The IESG asked for expert review of the draft 
>> by
>> MIME experts (as is normal for media type registrations). The 
>> reviewers
>> found a number of problems with the draft, and these issues 
>> potentially
>> affect all other RTP payload types.
>>
>> It was noted that the rules for registering media types under the
>> "text" top level type are stricter than those for audio and video
>> types. In particular, it is expected that text media types are, to 
>> some
>> extent,
>> readable even without the software that interprets them [RFC 2046].
>> This rule is derived from email client behaviour, where one wants to
>> pass the message to a dumb pager if there is no better display option,
>> and have something reasonable happen.
>>
>> This is clearly not the case for the "text/red" or "text/parityfec"
>> media types, which are error correcting codes sent over a stream of
>> unreliable datagrams, and require complex processing at the receiver
>> before text can be recovered.  The "text/t140" format is arguably
>> justified since packets contain plain text in UTF-8 format, and can be
>> directly displayed once they have been received.
>>
>> The discussion of our use of the "text" top level type led to a review
>> of our other uses of media types with RTP. It was noted that the rules
>> for media type registrations don't currently allow for domain specific
>> types: it is not legal to register a media type saying "this type is
>> defined only for use over RTP". This conflicts with the rules in RFC
>> 3555, and affects all the media types registered for use with RTP.
>>
>> After much discussion between the chairs, area directors, and MIME
>> experts, it was concluded that is it appropriate to relax the rules 
>> for
>> media type registrations in two ways:
>>
>>   - Allow domain specific media type registrations
>>
>>   - Allow complex text formats, provided they have restricted domain
>>     of applicability and do not affect backwards compatibility for
>>     email clients
>>
>> This change will be discussed on the <[email-masked]> mailing 
>> list.
>>
>> These updates will allow us to continue basically unchanged with our
>> use of
>> media types in AVT. However, they will take time to complete, since we
>> must update the media type registration rules for both MIME and RTP.
>>
>> The immediate consequence for the AVT working group is that the
>> publication of draft-ietf-avt-text-red-05.txt may be slightly delayed
>> (we do not expect any change to this draft, but it cannot be published
>> until the MIME type registration rules have changed). In addition, the
>> media type registration guidelines in RFC 3555 will need to be 
>> updated.
>> The chairs will co-ordinate this - please contact us if you have any
>> questions on the change.
>>
>> In future, as new RTP payload formats are developed, we will require
>> expert
>> review of the media type registration as part of the working group 
>> last
>> call process. Please contact the chairs for guidance on the procedure
>> for this review, when you believe your draft is ready for working 
>> group
>> last call. We will not forward drafts to the IESG for publication
>> unless they have received such review.
>>
>> --
>> Colin Perkins
>> http://csperkins.org/
>>
>>
>> _______________________________________________
>> Audio/Video Transport Working Group
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/avt

From: randy at qualcomm.com (Randall Gellens)
Date: Thu Sep 16 09:16:21 2004
Subject: Review Request: The Codecs Parameter for "Bucket" Media Types
Message-ID: <p06200804bd359fa3d347@[12.105.246.78]>

draft-gellens-mime-bucket-00 proposes adding a new parameter to 
certain media types:

Abstract

     Several MIME type/subtype combinations exist which can contain
     different media formats.  A receiving agent thus needs to examine
     the details of such media content to determine if the specific
     elements can be rendered given an available set of codecs.
     Especially when the end system has limited resources, or the
     connection to the end system has limited bandwidth, it would be
     helpful to know from the Content-Type alone if the content can be
     rendered.

     This document adds a new parameter, "codecs", to various
     type/subtype combinations to allow for unambiguous specification of
     the codecs required to support the media formats contained within.

     By labelling content with the specific codecs required to render the
     contained media, receiving systems can determine if the codecs are
     supported by the end system, and if not, can take appropriate action
     (such as rejecting the content, sending notification of the
     situation, transcoding the content to a supported type, fetching and
     installing the required codecs, etc.)
>From [email-masked]  Sat Aug 21 00:39:10 2004
From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Thu Sep 16 09:16:26 2004
Subject: fyi: draft-freed-mime-p4-04 morphs into
 draft-freed-media-type-reg-01 and draft-freed-mime-p4-05
Message-ID: <[email-masked]>

Note that draft-freed-mime-p4-04 has been apparently superseded by 
draft-freed-media-type-reg-01 and draft-freed-mime-p4-05

MartinD -- your nice page..

  http://www.w3.org/2002/06/registering-mediatype.html

..will need some minor updating. 

JeffH

From: randy at qualcomm.com (Randall Gellens)
Date: Tue Jan  3 16:22:47 2006
Subject: Review Request: The Codecs Parameter for "Bucket" Media Types
Message-ID: <p06200804bd359fa3d347@[12.105.246.78]>

draft-gellens-mime-bucket-00 proposes adding a new parameter to 
certain media types:

Abstract

     Several MIME type/subtype combinations exist which can contain
     different media formats.  A receiving agent thus needs to examine
     the details of such media content to determine if the specific
     elements can be rendered given an available set of codecs.
     Especially when the end system has limited resources, or the
     connection to the end system has limited bandwidth, it would be
     helpful to know from the Content-Type alone if the content can be
     rendered.

     This document adds a new parameter, "codecs", to various
     type/subtype combinations to allow for unambiguous specification of
     the codecs required to support the media formats contained within.

     By labelling content with the specific codecs required to render the
     contained media, receiving systems can determine if the codecs are
     supported by the end system, and if not, can take appropriate action
     (such as rejecting the content, sending notification of the
     situation, transcoding the content to a supported type, fetching and
     installing the required codecs, etc.)