Subject: [KOffice 1.2] app/vnd.kde.{kword,kspread,kpresenter,kformula,kchart,kivio,kontour,karbon}
From: [email-masked] ([email-masked])
Date: Wed, 29 May 2002 01:49:31 -0700 (PDT)

> Please find attached the registrations for the KOffice 1.2 mime types.
> Their texts are equal except for the names of applications and the file
> extensions, so you only need to read one.

These look pretty reasonable to me. Please remember that you need to
submit these to IANA yourself; submission to this list is for
review purposes only and does not constitute a request for registration.

				Ned

From: [email-masked] (Marc Mutz)
Date: Sun, 26 May 2002 21:21:48 +0200
Subject: [KOffice 1.2] app/vnd.kde.{kword,kspread,kpresenter,kformula,kchart,kivio,kontour,karbon}
Message-ID: <[email-masked]>

--Boundary-00=_MXT88KmVX3mLPIT
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: clearsigned data
Content-Disposition: inline

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Please find attached the registrations for the KOffice 1.2 mime types.=20
Their texts are equal except for the names of applications and the file=20
extensions, so you only need to read one.

Marc

=2D --=20
Marc Mutz <[email-masked]>
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE88TXM3oWD+L2/6DgRApzFAKCBX5pzJb0nfwM0scg8xSRXI2G6CgCeK2vz
/DlErD27Dvv5lKVZW4JSdDw=3D
=3DovXo
=2D----END PGP SIGNATURE-----

--Boundary-00=_MXT88KmVX3mLPIT
Content-Type: text/plain;
  charset="us-ascii";
  name="koffice-mime-types.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="koffice-mime-types.txt"

***KWord***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kword

MIME media type name: application

MIME subtype name: vnd.kde.kword

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, KWord documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of KWord feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the KWord document itself.

        KWord documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The KWord user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kword mime type for the obsolete format.

Published specification:

        A KWord document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in KWord can either be completely embedded
        in the KWord document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. KWord.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kword
        File extensions: KWT, KWD
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***KSpread***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kspread

MIME media type name: application

MIME subtype name: vnd.kde.kspread

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, KSpread documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of KSpread feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the KSpread document itself.

        KSpread documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The KSpread user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kspread mime type for the obsolete format.

Published specification:

        A KSpread document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in KSpread can either be completely embedded
        in the KSpread document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. KSpread.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kspread
        File extensions: KSP
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***KPresenter***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kpresenter

MIME media type name: application

MIME subtype name: vnd.kde.kpresenter

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, KPresenter documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of KPresenter feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the KPresenter document itself.

        KPresenter documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The KPresenter user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kpresenter mime type for the obsolete format.

Published specification:

        A KPresenter document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in KPresenter can either be completely embedded
        in the KPresenter document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. KPresenter.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kpresenter
        File extensions: KPR, KPT
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***KFormula***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kformula

MIME media type name: application

MIME subtype name: vnd.kde.kformula

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, KFormula documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of KFormula feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the KFormula document itself.

        KFormula documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The KFormula user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kformula mime type for the obsolete format.

Published specification:

        A KFormula document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in KFormula can either be completely embedded
        in the KFormula document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. KFormula.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kformula
        File extensions: KFO
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***KChart***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kchart

MIME media type name: application

MIME subtype name: vnd.kde.kchart

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, KChart documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of KChart feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the KChart document itself.

        KChart documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The KChart user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kchart mime type for the obsolete format.

Published specification:

        A KChart document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in KChart can either be completely embedded
        in the KChart document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. KChart.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kchart
        File extensions: CHRT
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***Kivio***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kivio

MIME media type name: application

MIME subtype name: vnd.kde.kivio

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, Kivio documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of Kivio feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the Kivio document itself.

        Kivio documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The Kivio user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kivio mime type for the obsolete format.

Published specification:

        A Kivio document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in Kivio can either be completely embedded
        in the Kivio document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. Kivio.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kivio
        File extensions: FLW
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***Kontour***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kontour

MIME media type name: application

MIME subtype name: vnd.kde.kontour

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, Kontour documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of Kontour feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the Kontour document itself.

        Kontour documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The Kontour user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kontour mime type for the obsolete format.

Published specification:

        A Kontour document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in Kontour can either be completely embedded
        in the Kontour document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. Kontour.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kontour
        File extensions: KON
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***Karbon***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.karbon

MIME media type name: application

MIME subtype name: vnd.kde.karbon

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, Karbon documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of Karbon feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the Karbon document itself.

        Karbon documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The Karbon user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-karbon mime type for the obsolete format.

Published specification:

        A Karbon document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in Karbon can either be completely embedded
        in the Karbon document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. Karbon.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.karbon
        File extensions: KARBON
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

--Boundary-00=_MXT88KmVX3mLPIT--

From: [email-masked] (David Hopwood)
Date: Fri, 24 May 2002 03:31:19 +0000
Subject: application/pkix-pkipath
References: <[email-masked]>
Message-ID: <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

Peter Williams wrote:
> All certs must comply with PKIX, it says. There are very real
> communities of TLS users who use a non-PKIX profile of certs.

- From RFC 2246, section 7.4.2:

# All certificate profiles, key and cryptographic formats are defined
# by the IETF PKIX working group [ref. to RFC 2459].

(In context, this applies only to X.509 formats. If other formats were
added they obviously wouldn't be defined by PKIX. This should be made
clearer in RFC2246-bis.)

Which communities of TLS users are (deliberately, rather than just as
a result of bugs) using non-PKIX-conformant X.509 certs, and why?

> They should not be excluded from the use of the TLS proposed extensions.
> There is nothing inherent in the nature of TLS or the extended handling
> that requires that PKIX-designated controls be enforced.

That's true, but specifying PKIX improves interoperability. It's not a
new requirement; it is just clarifying how a requirement that is already
in RFC 2246 applies for this type.

> TLS should continue to be able to maintain current
> interoperability AND exploit some of the newer extensions
> even when certificates are not the means of distributing
> public keys for the asymmetric cipher suites, as per
> traditional SSL design.

We (the extensions spec authors) were very careful not to do anything that
would preclude or create problems for other public key authentication
methods than X.509 certs. I don't see any good argument for using
non-PKIX X.509 certs, though.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

From: [email-masked] (David Hopwood)
Date: Fri, 24 May 2002 03:24:17 +0000
Subject: [ietf-tls] Re: application/pkix-pkipath
References: <[email-masked]>
Message-ID: <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

"Housley, Russ" wrote:
> The registration says: "... an update to [PKIX] ..."
> 
> That update is (finally) finished.  See RFC 3280.
> Please reference RFC 3280 (not RFC 2459).

Thanks, this will be fixed as follows:

Change the [PKIX] reference to

   [PKIX] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet Public
   Key Infrastructure - Certificate and Certificate Revocation List
   (CRL) Profile", IETF RFC 3280, April 2002.

and change the sentence in the registration to just
"All Certificates MUST conform to [PKIX]."

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

From: [email-masked] (David Hopwood)
Date: Thu, 23 May 2002 16:08:14 +0000
Subject: application/pkix-pkipath
Message-ID: <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

The following template is from the Standards Track I-D
<draft-ietf-tls-extensions-04.txt>, which has just been submitted
for Last Call in the TLS WG. It's intended to be consistent with the
types application/pkix-{cert,crl} from RFC 2585.

(Note: Reply-To is set to the ietf-types list only.)

   To: [email-masked]
   Subject: Registration of MIME media type application/pkix-pkipath

   MIME media type name: application

   MIME subtype name: pkix-pkipath

   Required parameters: none

   Optional parameters: version (default value is "1")

   Encoding considerations:
      This MIME type is a DER encoding of the ASN.1 type PkiPath,
      defined as follows:

         PkiPath ::= SEQUENCE OF Certificate

         PkiPath is used to represent a certification path. Within the
         sequence, the order of certificates is such that the subject of
         the first certificate is the issuer of the second certificate,
         etc.

      This is identical to the definition that will be published in
      [X509-4th-TC1]; note that it is different from that in [X509-4th].

      All Certificates MUST conform to [PKIX] (an update to [PKIX] is
      in preparation, and should be followed when it is published).
      DER (as opposed to BER) encoding MUST be used. If this type is
      sent over a 7-bit transport, base64 encoding SHOULD be used.

   Security considerations:
      The security considerations of [X509-4th] and [PKIX] (or any
      updates to them) apply, as well as those of any protocol that uses
      this type (e.g. TLS).

      Note that this type only specifies a certificate chain that
      can be assessed for validity according to the relying party's
      existing configuration of trusted CAs; it is not intended to be
      used to specify any change to that configuration.

   Interoperability considerations:
      No specific interoperability problems are known with this type,
      but for recommendations relating to X.509 certificates in general,
      see [PKIX].

   Published specification: <draft-ietf-tls-extensions-04.txt> and
      [PKIX].

   Applications which use this media type: TLS. It may also be used by
      other protocols, or for general interchange of PKIX certificate
      chains.

   Additional information:
      Magic number(s): DER-encoded ASN.1 can be easily recognised.
         Further parsing is required to distinguish from other ASN.1
         types.
      File extension(s): .pkipath
      Macintosh File Type Code(s): not specified

   Person & email address to contact for further information:
      Magnus Nystrom <[email-masked]>

   Intended usage: COMMON

   Author/Change controller:
      Magnus Nystrom <[email-masked]>

Normative References

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

   [PKIX] R. Housley, W. Ford, W. Polk, and D. Solo, "Internet Public
   Key Infrastructure: Part I: X.509 Certificate and CRL Profile", IETF
   RFC 2459, January 1999.

   [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001,
   "Information Systems - Open Systems Interconnection - The Directory:
   Public key and attribute certificate frameworks."

   [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
   ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to ISO/IEC
   9594:8:2001.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:32 2006
Subject: [KOffice 1.2] app/vnd.kde.{kword,kspread,kpresenter,kformula,kchart,kivio,kontour,karbon}
In-Reply-To: "Your message dated Sun, 26 May 2002 21:21:48 +0200" <[email-masked]>
Message-ID: <[email-masked]>

> Please find attached the registrations for the KOffice 1.2 mime types.
> Their texts are equal except for the names of applications and the file
> extensions, so you only need to read one.

These look pretty reasonable to me. Please remember that you need to
submit these to IANA yourself; submission to this list is for
review purposes only and does not constitute a request for registration.

				Ned

From: [email-masked] ([email-masked])
Date: Wed, 29 May 2002 01:49:31 -0700 (PDT)
Subject: [KOffice 1.2] app/vnd.kde.{kword,kspread,kpresenter,kformula,kchart,kivio,kontour,karbon}
In-Reply-To: "Your message dated Sun, 26 May 2002 21:21:48 +0200" <[email-masked]>
Message-ID: <[email-masked]>

> Please find attached the registrations for the KOffice 1.2 mime types.
> Their texts are equal except for the names of applications and the file
> extensions, so you only need to read one.

These look pretty reasonable to me. Please remember that you need to
submit these to IANA yourself; submission to this list is for
review purposes only and does not constitute a request for registration.

				Ned

From: mutz at kde.org (Marc Mutz)
Date: Tue Jan  3 16:22:32 2006
Subject: [KOffice 1.2] app/vnd.kde.{kword,kspread,kpresenter,kformula,kchart,kivio,kontour,karbon}
Message-ID: <[email-masked]>

Hi!

Please find attached the registrations for the KOffice 1.2 mime types. 
Their texts are equal except for the names of applications and the file 
extensions, so you only need to read one.

Marc

- -- 
Marc Mutz <[email-masked]>
-------------- next part --------------
***KWord***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kword

MIME media type name: application

MIME subtype name: vnd.kde.kword

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, KWord documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of KWord feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the KWord document itself.

        KWord documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The KWord user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kword mime type for the obsolete format.

Published specification:

        A KWord document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in KWord can either be completely embedded
        in the KWord document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. KWord.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kword
        File extensions: KWT, KWD
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***KSpread***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kspread

MIME media type name: application

MIME subtype name: vnd.kde.kspread

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, KSpread documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of KSpread feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the KSpread document itself.

        KSpread documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The KSpread user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kspread mime type for the obsolete format.

Published specification:

        A KSpread document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in KSpread can either be completely embedded
        in the KSpread document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. KSpread.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kspread
        File extensions: KSP
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***KPresenter***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kpresenter

MIME media type name: application

MIME subtype name: vnd.kde.kpresenter

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, KPresenter documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of KPresenter feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the KPresenter document itself.

        KPresenter documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The KPresenter user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kpresenter mime type for the obsolete format.

Published specification:

        A KPresenter document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in KPresenter can either be completely embedded
        in the KPresenter document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. KPresenter.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kpresenter
        File extensions: KPR, KPT
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***KFormula***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kformula

MIME media type name: application

MIME subtype name: vnd.kde.kformula

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, KFormula documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of KFormula feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the KFormula document itself.

        KFormula documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The KFormula user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kformula mime type for the obsolete format.

Published specification:

        A KFormula document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in KFormula can either be completely embedded
        in the KFormula document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. KFormula.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kformula
        File extensions: KFO
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***KChart***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kchart

MIME media type name: application

MIME subtype name: vnd.kde.kchart

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, KChart documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of KChart feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the KChart document itself.

        KChart documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The KChart user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kchart mime type for the obsolete format.

Published specification:

        A KChart document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in KChart can either be completely embedded
        in the KChart document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. KChart.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kchart
        File extensions: CHRT
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***Kivio***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kivio

MIME media type name: application

MIME subtype name: vnd.kde.kivio

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, Kivio documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of Kivio feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the Kivio document itself.

        Kivio documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The Kivio user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kivio mime type for the obsolete format.

Published specification:

        A Kivio document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in Kivio can either be completely embedded
        in the Kivio document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. Kivio.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kivio
        File extensions: FLW
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***Kontour***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kontour

MIME media type name: application

MIME subtype name: vnd.kde.kontour

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, Kontour documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of Kontour feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the Kontour document itself.

        Kontour documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The Kontour user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kontour mime type for the obsolete format.

Published specification:

        A Kontour document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in Kontour can either be completely embedded
        in the Kontour document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. Kontour.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kontour
        File extensions: KON
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***Karbon***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.karbon

MIME media type name: application

MIME subtype name: vnd.kde.karbon

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, Karbon documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of Karbon feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the Karbon document itself.

        Karbon documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The Karbon user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-karbon mime type for the obsolete format.

Published specification:

        A Karbon document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in Karbon can either be completely embedded
        in the Karbon document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. Karbon.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.karbon
        File extensions: KARBON
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

From: [email-masked] (Marc Mutz)
Date: Sun, 26 May 2002 21:21:48 +0200
Subject: [KOffice 1.2] app/vnd.kde.{kword,kspread,kpresenter,kformula,kchart,kivio,kontour,karbon}
Message-ID: <[email-masked]>

--Boundary-00=_MXT88KmVX3mLPIT
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: clearsigned data
Content-Disposition: inline

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Please find attached the registrations for the KOffice 1.2 mime types.=20
Their texts are equal except for the names of applications and the file=20
extensions, so you only need to read one.

Marc

=2D --=20
Marc Mutz <[email-masked]>
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE88TXM3oWD+L2/6DgRApzFAKCBX5pzJb0nfwM0scg8xSRXI2G6CgCeK2vz
/DlErD27Dvv5lKVZW4JSdDw=3D
=3DovXo
=2D----END PGP SIGNATURE-----

--Boundary-00=_MXT88KmVX3mLPIT
Content-Type: text/plain;
  charset="us-ascii";
  name="koffice-mime-types.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="koffice-mime-types.txt"

***KWord***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kword

MIME media type name: application

MIME subtype name: vnd.kde.kword

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, KWord documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of KWord feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the KWord document itself.

        KWord documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The KWord user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kword mime type for the obsolete format.

Published specification:

        A KWord document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in KWord can either be completely embedded
        in the KWord document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. KWord.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kword
        File extensions: KWT, KWD
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***KSpread***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kspread

MIME media type name: application

MIME subtype name: vnd.kde.kspread

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, KSpread documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of KSpread feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the KSpread document itself.

        KSpread documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The KSpread user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kspread mime type for the obsolete format.

Published specification:

        A KSpread document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in KSpread can either be completely embedded
        in the KSpread document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. KSpread.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kspread
        File extensions: KSP
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***KPresenter***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kpresenter

MIME media type name: application

MIME subtype name: vnd.kde.kpresenter

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, KPresenter documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of KPresenter feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the KPresenter document itself.

        KPresenter documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The KPresenter user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kpresenter mime type for the obsolete format.

Published specification:

        A KPresenter document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in KPresenter can either be completely embedded
        in the KPresenter document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. KPresenter.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kpresenter
        File extensions: KPR, KPT
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***KFormula***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kformula

MIME media type name: application

MIME subtype name: vnd.kde.kformula

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, KFormula documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of KFormula feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the KFormula document itself.

        KFormula documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The KFormula user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kformula mime type for the obsolete format.

Published specification:

        A KFormula document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in KFormula can either be completely embedded
        in the KFormula document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. KFormula.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kformula
        File extensions: KFO
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***KChart***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kchart

MIME media type name: application

MIME subtype name: vnd.kde.kchart

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, KChart documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of KChart feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the KChart document itself.

        KChart documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The KChart user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kchart mime type for the obsolete format.

Published specification:

        A KChart document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in KChart can either be completely embedded
        in the KChart document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. KChart.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kchart
        File extensions: CHRT
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***Kivio***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kivio

MIME media type name: application

MIME subtype name: vnd.kde.kivio

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, Kivio documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of Kivio feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the Kivio document itself.

        Kivio documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The Kivio user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kivio mime type for the obsolete format.

Published specification:

        A Kivio document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in Kivio can either be completely embedded
        in the Kivio document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. Kivio.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kivio
        File extensions: FLW
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***Kontour***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.kontour

MIME media type name: application

MIME subtype name: vnd.kde.kontour

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, Kontour documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of Kontour feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the Kontour document itself.

        Kontour documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The Kontour user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-kontour mime type for the obsolete format.

Published specification:

        A Kontour document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in Kontour can either be completely embedded
        in the Kontour document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. Kontour.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.kontour
        File extensions: KON
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

***Karbon***

To: [email-masked]
Subject: Registration of MIME media type application/vnd.kde.karbon

MIME media type name: application

MIME subtype name: vnd.kde.karbon

Required parameters: none

Optional parameters: none

Encoding considerations: Binary or base64 required

Security considerations:

        As of this writing, Karbon documents do not contain any active
        content. As such, it is believed that usage of this mimetype
        does not introduce security concerns other than those already
        inherent in ZIP archives, XML files and supported image files.

        It is expected that later versions of Karbon feature scripting
        and macro recording facilities. It is, however, not intended
        to include active content into the Karbon document itself.

        Karbon documents include document metadata such as the name of
        the author, etc. However, none of this data is written
        automatically. The Karbon user has full control over what
        metadata is to be included and must actively request the
        inclusion. As such, the use of this mimetype does not lead to
        hidden leaking of possibly sensitive data.

Interoperability considerations:

        Earlier versions of KOffice (<= 1.1) used gzip-compressed UNIX
        tar files as archive format. It is expected that this obsolete
        format will die out soon after the first release of KOffice
        1.2. Thus, this registration does not apply to the obsolete
        format. Implementations are expected to use the old
        application/x-karbon mime type for the obsolete format.

Published specification:

        A Karbon document consists of a series of XML streams and
        externally generated content which are bundled together as a
        ZIP archive.

        Any content placed in Karbon can either be completely embedded
        in the Karbon document or can be linked to using URIs.

        The DTDs used in KOffice can be obtained from
        http://www.koffice.org/DTD/.

        A description of the storage format is contained in the source
        code distribution (lib/store/SPEC). The current version can be
        obtained online via KDE's WebCVS interface:
        http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/lib/store/SPEC

Applications which use this media type:

        All applications in the KDE KOffice Office Suite, esp. Karbon.

Additional information:

        Magic numbers: This is an entry that can be used with the
                       UNIX file(1) command's magic(4) file:
                 0    string   PK\003\004
                 >30  string   mimetype
                 >>38 string   application/vnd.kde.karbon
        File extensions: KARBON
        Macintosh File Type Codes: n/a

Person & email address to contact for further information:

        David Faure <[email-masked]>

Intended usage: COMMON

Author/Change contoller: Marc Mutz <[email-masked]>

--Boundary-00=_MXT88KmVX3mLPIT--

From: david.hopwood at zetnet.co.uk (David Hopwood)
Date: Tue Jan  3 16:22:32 2006
Subject: application/pkix-pkipath
References: <[email-masked]>
Message-ID: <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

Peter Williams wrote:
> All certs must comply with PKIX, it says. There are very real
> communities of TLS users who use a non-PKIX profile of certs.

- From RFC 2246, section 7.4.2:

# All certificate profiles, key and cryptographic formats are defined
# by the IETF PKIX working group [ref. to RFC 2459].

(In context, this applies only to X.509 formats. If other formats were
added they obviously wouldn't be defined by PKIX. This should be made
clearer in RFC2246-bis.)

Which communities of TLS users are (deliberately, rather than just as
a result of bugs) using non-PKIX-conformant X.509 certs, and why?

> They should not be excluded from the use of the TLS proposed extensions.
> There is nothing inherent in the nature of TLS or the extended handling
> that requires that PKIX-designated controls be enforced.

That's true, but specifying PKIX improves interoperability. It's not a
new requirement; it is just clarifying how a requirement that is already
in RFC 2246 applies for this type.

> TLS should continue to be able to maintain current
> interoperability AND exploit some of the newer extensions
> even when certificates are not the means of distributing
> public keys for the asymmetric cipher suites, as per
> traditional SSL design.

We (the extensions spec authors) were very careful not to do anything that
would preclude or create problems for other public key authentication
methods than X.509 certs. I don't see any good argument for using
non-PKIX X.509 certs, though.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

From: david.hopwood at zetnet.co.uk (David Hopwood)
Date: Tue Jan  3 16:22:32 2006
Subject: [ietf-tls] Re: application/pkix-pkipath
References: <[email-masked]>
Message-ID: <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

"Housley, Russ" wrote:
> The registration says: "... an update to [PKIX] ..."
> 
> That update is (finally) finished.  See RFC 3280.
> Please reference RFC 3280 (not RFC 2459).

Thanks, this will be fixed as follows:

Change the [PKIX] reference to

   [PKIX] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet Public
   Key Infrastructure - Certificate and Certificate Revocation List
   (CRL) Profile", IETF RFC 3280, April 2002.

and change the sentence in the registration to just
"All Certificates MUST conform to [PKIX]."

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

From: [email-masked] (David Hopwood)
Date: Fri, 24 May 2002 03:31:19 +0000
Subject: application/pkix-pkipath
References: <[email-masked]>
Message-ID: <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

Peter Williams wrote:
> All certs must comply with PKIX, it says. There are very real
> communities of TLS users who use a non-PKIX profile of certs.

- From RFC 2246, section 7.4.2:

# All certificate profiles, key and cryptographic formats are defined
# by the IETF PKIX working group [ref. to RFC 2459].

(In context, this applies only to X.509 formats. If other formats were
added they obviously wouldn't be defined by PKIX. This should be made
clearer in RFC2246-bis.)

Which communities of TLS users are (deliberately, rather than just as
a result of bugs) using non-PKIX-conformant X.509 certs, and why?

> They should not be excluded from the use of the TLS proposed extensions.
> There is nothing inherent in the nature of TLS or the extended handling
> that requires that PKIX-designated controls be enforced.

That's true, but specifying PKIX improves interoperability. It's not a
new requirement; it is just clarifying how a requirement that is already
in RFC 2246 applies for this type.

> TLS should continue to be able to maintain current
> interoperability AND exploit some of the newer extensions
> even when certificates are not the means of distributing
> public keys for the asymmetric cipher suites, as per
> traditional SSL design.

We (the extensions spec authors) were very careful not to do anything that
would preclude or create problems for other public key authentication
methods than X.509 certs. I don't see any good argument for using
non-PKIX X.509 certs, though.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

From: [email-masked] (David Hopwood)
Date: Fri, 24 May 2002 03:24:17 +0000
Subject: [ietf-tls] Re: application/pkix-pkipath
References: <[email-masked]>
Message-ID: <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

"Housley, Russ" wrote:
> The registration says: "... an update to [PKIX] ..."
> 
> That update is (finally) finished.  See RFC 3280.
> Please reference RFC 3280 (not RFC 2459).

Thanks, this will be fixed as follows:

Change the [PKIX] reference to

   [PKIX] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet Public
   Key Infrastructure - Certificate and Certificate Revocation List
   (CRL) Profile", IETF RFC 3280, April 2002.

and change the sentence in the registration to just
"All Certificates MUST conform to [PKIX]."

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

From: david.hopwood at zetnet.co.uk (David Hopwood)
Date: Tue Jan  3 16:22:31 2006
Subject: application/pkix-pkipath
Message-ID: <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

The following template is from the Standards Track I-D
<draft-ietf-tls-extensions-04.txt>, which has just been submitted
for Last Call in the TLS WG. It's intended to be consistent with the
types application/pkix-{cert,crl} from RFC 2585.

(Note: Reply-To is set to the ietf-types list only.)

   To: [email-masked]
   Subject: Registration of MIME media type application/pkix-pkipath

   MIME media type name: application

   MIME subtype name: pkix-pkipath

   Required parameters: none

   Optional parameters: version (default value is "1")

   Encoding considerations:
      This MIME type is a DER encoding of the ASN.1 type PkiPath,
      defined as follows:

         PkiPath ::= SEQUENCE OF Certificate

         PkiPath is used to represent a certification path. Within the
         sequence, the order of certificates is such that the subject of
         the first certificate is the issuer of the second certificate,
         etc.

      This is identical to the definition that will be published in
      [X509-4th-TC1]; note that it is different from that in [X509-4th].

      All Certificates MUST conform to [PKIX] (an update to [PKIX] is
      in preparation, and should be followed when it is published).
      DER (as opposed to BER) encoding MUST be used. If this type is
      sent over a 7-bit transport, base64 encoding SHOULD be used.

   Security considerations:
      The security considerations of [X509-4th] and [PKIX] (or any
      updates to them) apply, as well as those of any protocol that uses
      this type (e.g. TLS).

      Note that this type only specifies a certificate chain that
      can be assessed for validity according to the relying party's
      existing configuration of trusted CAs; it is not intended to be
      used to specify any change to that configuration.

   Interoperability considerations:
      No specific interoperability problems are known with this type,
      but for recommendations relating to X.509 certificates in general,
      see [PKIX].

   Published specification: <draft-ietf-tls-extensions-04.txt> and
      [PKIX].

   Applications which use this media type: TLS. It may also be used by
      other protocols, or for general interchange of PKIX certificate
      chains.

   Additional information:
      Magic number(s): DER-encoded ASN.1 can be easily recognised.
         Further parsing is required to distinguish from other ASN.1
         types.
      File extension(s): .pkipath
      Macintosh File Type Code(s): not specified

   Person & email address to contact for further information:
      Magnus Nystrom <[email-masked]>

   Intended usage: COMMON

   Author/Change controller:
      Magnus Nystrom <[email-masked]>

Normative References

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

   [PKIX] R. Housley, W. Ford, W. Polk, and D. Solo, "Internet Public
   Key Infrastructure: Part I: X.509 Certificate and CRL Profile", IETF
   RFC 2459, January 1999.

   [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001,
   "Information Systems - Open Systems Interconnection - The Directory:
   Public key and attribute certificate frameworks."

   [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
   ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to ISO/IEC
   9594:8:2001.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

From: [email-masked] (David Hopwood)
Date: Thu, 23 May 2002 16:08:14 +0000
Subject: application/pkix-pkipath
Message-ID: <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

The following template is from the Standards Track I-D
<draft-ietf-tls-extensions-04.txt>, which has just been submitted
for Last Call in the TLS WG. It's intended to be consistent with the
types application/pkix-{cert,crl} from RFC 2585.

(Note: Reply-To is set to the ietf-types list only.)

   To: [email-masked]
   Subject: Registration of MIME media type application/pkix-pkipath

   MIME media type name: application

   MIME subtype name: pkix-pkipath

   Required parameters: none

   Optional parameters: version (default value is "1")

   Encoding considerations:
      This MIME type is a DER encoding of the ASN.1 type PkiPath,
      defined as follows:

         PkiPath ::= SEQUENCE OF Certificate

         PkiPath is used to represent a certification path. Within the
         sequence, the order of certificates is such that the subject of
         the first certificate is the issuer of the second certificate,
         etc.

      This is identical to the definition that will be published in
      [X509-4th-TC1]; note that it is different from that in [X509-4th].

      All Certificates MUST conform to [PKIX] (an update to [PKIX] is
      in preparation, and should be followed when it is published).
      DER (as opposed to BER) encoding MUST be used. If this type is
      sent over a 7-bit transport, base64 encoding SHOULD be used.

   Security considerations:
      The security considerations of [X509-4th] and [PKIX] (or any
      updates to them) apply, as well as those of any protocol that uses
      this type (e.g. TLS).

      Note that this type only specifies a certificate chain that
      can be assessed for validity according to the relying party's
      existing configuration of trusted CAs; it is not intended to be
      used to specify any change to that configuration.

   Interoperability considerations:
      No specific interoperability problems are known with this type,
      but for recommendations relating to X.509 certificates in general,
      see [PKIX].

   Published specification: <draft-ietf-tls-extensions-04.txt> and
      [PKIX].

   Applications which use this media type: TLS. It may also be used by
      other protocols, or for general interchange of PKIX certificate
      chains.

   Additional information:
      Magic number(s): DER-encoded ASN.1 can be easily recognised.
         Further parsing is required to distinguish from other ASN.1
         types.
      File extension(s): .pkipath
      Macintosh File Type Code(s): not specified

   Person & email address to contact for further information:
      Magnus Nystrom <[email-masked]>

   Intended usage: COMMON

   Author/Change controller:
      Magnus Nystrom <[email-masked]>

Normative References

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

   [PKIX] R. Housley, W. Ford, W. Polk, and D. Solo, "Internet Public
   Key Infrastructure: Part I: X.509 Certificate and CRL Profile", IETF
   RFC 2459, January 1999.

   [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001,
   "Information Systems - Open Systems Interconnection - The Directory:
   Public key and attribute certificate frameworks."

   [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
   ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to ISO/IEC
   9594:8:2001.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip