Subject: Re: [ietf-types] Request for registration of application/gzip and application/zlib
From: Ned Freed <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: John R Levine <[email-masked]>, Bjoern Hoehrmann <[email-masked]>, [email-masked]
Date: Thu, 23 Feb 2012 14:44:21 -0800 (PST)
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>

> As such, the requirement that security considerations for standards tree
> registration trumps any "but there is a better location" argument that can be
> made, because said better location doesn't actually exist and isn't going to
> exist.

Sorry, this was supposed to read:

  As such, the requirement that security considerations for standards tree
  registrations be as complete as possible trumps any "but there is a better
  location" argument that can be made, because said better location doesn't
  actually exist and isn't going to exist.

Date: Thu, 23 Feb 2012 14:33:12 -0800 (PST)
From: Ned Freed <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Cc: John R Levine <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Request for registration of application/gzip and application/zlib

> * Ned Freed wrote:
> >> * John R Levine wrote:
> >> >    Encoding considerations: needs base64 or other encoding that allows
> >> >    arbitrary binary data
> >
> >> The value should be "8bit" (for both types).
> >
> >???? These are binary formats, plain and simple. There's no encoding included
> >in them that would result in line-oriented output.
> >
> >I don't mind changing the wording to simply say "binary" if that is clearer,
> >but "8bit" is flat-out incorrect.

> My apologies, I meant "binary". The nomenclature does confuse me, and I
> looked the definitions up again when making the comment, but apparently
> it came out wrong. The point is that RFC 4288 says "one of these key-
> words", not free-form text.

The keyword absolutely needs to be included, but free form text is often
helpful in explaining various nuances, and I see nothing in RFC 4288 that
actually prohibits it.

> >> >    Additional information:
> >> >
> >> >       Magic number(s): first byte is usually 0x78 but can also be 0x08,
> >> >       0x18, 0x28, 0x38, 0x48, 0x58, or 0x68.
> >
> >> This is confusing.
> >
> >Then suggest text. Not sure how else you can say this.

> I have not checked whether the above is all that can be said, but if it
> is, something like "The first byte is one of ... where 0x78 is the most
> common".

That also works for me, but frankly I don't think it is any clearer.

> >> >       File extension(s): none
> >> >       Macintosh file type code(s): none
> >> >
> >> >    Person and email address to contact for further information: see
> >> >    http://www.zlib.net/
> >
> >> The form in RFC 4288 wants you to use "&" in place of "and".
> >
> >No, really, it doesn't. Nothing says the form has to be followed to this
> >degree.

> Well, I look at it from a automated data extraction perspective, and
> little details like this make it harder to develop such tools. There
> being no good reason to use "&" sometimes and "and" other times, I'd
> prefer consistency, but I do agree that this is not a blocker.

Um, I doubt very, very much there's any automation involved...

> >> >4.  Security Considerations
> >> >
> >> >    Zlib and gzip compression can be used to compress arbitrary binary
> >> >    data such as hostile executable code.  Also, data that purports to be
> >> >    in zlib or gzip format may not be, and fields that are supposed to be
> >> >    flags, lengths, or pointers, could contain anything.  Applications
> >> >    should treat any data with due scepticism.
> >
> >> I would prefer simply referencing the two format RFCs, the types as such
> >> do not introduce additional security considerations.
> >
> >This may need to be reworded to make it clearer, but AFAIK the point that these
> >formats decode automatically in some contexts and are therefore sometimes used
> >to get hostile code past overly simplistic scans is not mentioned in those
> >documents and *is* a known security concern. As such, it needs to be mentioned.

> That is something the format RFCs should discuss, it's not a media type
> issue. With HTTP for instance you do not have automatic decompression
> based on the media type, but rather in a separate mechanism.

As John already pointed out, the RFCs say what they say and that isn't going
to change. Expecting someone to republish an RFC for no other reason than
to change a security considerion of this sort is simply not realistic.

As such, the requirement that security considerations for standards tree
registration trumps any "but there is a better location" argument that can be
made, because said better location doesn't actually exist and isn't going to
exist.

				Ned

VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 22 Feb 2012 22:29:10 -0800
From: "John R. Levine" <[email-masked]>
To: "Bjoern Hoehrmann" <[email-masked]>
Cleverness: None detected
Cc: [email-masked]
Subject: Re: [ietf-types] Request for registration of application/gzip and application/zlib

>> ???? These are binary formats, plain and simple. There's no encoding included
>> in them that would result in line-oriented output.
>>
>> I don't mind changing the wording to simply say "binary" if that is clearer,
>> but "8bit" is flat-out incorrect.

I think I'll leave the current wording.

>>>>       Magic number(s): first byte is usually 0x78 but can also be 0x08,
>>>>       0x18, 0x28, 0x38, 0x48, 0x58, or 0x68.
>>
>>> This is confusing.
>>
>> Then suggest text. Not sure how else you can say this.
>
> I have not checked whether the above is all that can be said, ...

Why not?  It's RFC 1950, section 2.2.

>>>> 4.  Security Considerations
>>>>
>>>>    Zlib and gzip compression can be used to compress arbitrary binary
>>>>    data such as hostile executable code.  Also, data that purports to be
>>>>    in zlib or gzip format may not be, and fields that are supposed to be
>>>>    flags, lengths, or pointers, could contain anything.  Applications
>>>>    should treat any data with due scepticism.
>>
>>> I would prefer simply referencing the two format RFCs, the types as such
>>> do not introduce additional security considerations.

The draft does reference the two format RFCs.

>> This may need to be reworded to make it clearer, but AFAIK the point that these
>> formats decode automatically in some contexts and are therefore sometimes used
>> to get hostile code past overly simplistic scans is not mentioned in those
>> documents and *is* a known security concern. As such, it needs to be mentioned.
>
> That is something the format RFCs should discuss, it's not a media type
> issue. With HTTP for instance you do not have automatic decompression
> based on the media type, but rather in a separate mechanism.

Beyond the fact that the format RFCs were written 15 years ago and aren't 
going to change, the issue here is that MIME parts can be mislabelled. 
Zlib and gzip have an internal structure with pointers and table lookups, 
so data that claims to be zlib but isn't quite could provoke buffer 
overruns and other security holes.

By the way, HTTP has exactly the same vulnerability, since HTTP has gzip 
and deflate content codings.  See RFC 2616, sec 3.5.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

From: Bjoern Hoehrmann <[email-masked]>
To: "John R. Levine" <[email-masked]>
Date: Thu, 23 Feb 2012 00:04:48 +0100
Cc: [email-masked]
Subject: Re: [ietf-types] Request for registration of application/gzip and application/zlib

* John R. Levine wrote:
>>>> The draft is here:
>>>>
>>>> https://datatracker.ietf.org/doc/draft-levine-application-gzip/
>
>For comments, please see the draft, not just the excepts I posted.  Most 
>of Bjoern's comments are already addressed in the current draft.

If you mean draft-levine-application-gzip-00 then the excerpts seem to
be quite equivalent to the draft, and I do not see a more recent draft.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From: Bjoern Hoehrmann <[email-masked]>
To: Ned Freed <[email-masked]>
Date: Wed, 22 Feb 2012 23:55:24 +0100
Cc: John R Levine <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Request for registration of application/gzip and application/zlib

* Ned Freed wrote:
>> * John R Levine wrote:
>> >    Encoding considerations: needs base64 or other encoding that allows
>> >    arbitrary binary data
>
>> The value should be "8bit" (for both types).
>
>???? These are binary formats, plain and simple. There's no encoding included
>in them that would result in line-oriented output. 
>
>I don't mind changing the wording to simply say "binary" if that is clearer,
>but "8bit" is flat-out incorrect.

My apologies, I meant "binary". The nomenclature does confuse me, and I
looked the definitions up again when making the comment, but apparently
it came out wrong. The point is that RFC 4288 says "one of these key-
words", not free-form text.

>> >    Additional information:
>> >
>> >       Magic number(s): first byte is usually 0x78 but can also be 0x08,
>> >       0x18, 0x28, 0x38, 0x48, 0x58, or 0x68.
>
>> This is confusing.
>
>Then suggest text. Not sure how else you can say this.

I have not checked whether the above is all that can be said, but if it
is, something like "The first byte is one of ... where 0x78 is the most
common".

>> >       File extension(s): none
>> >       Macintosh file type code(s): none
>> >
>> >    Person and email address to contact for further information: see
>> >    http://www.zlib.net/
>
>> The form in RFC 4288 wants you to use "&" in place of "and".
>
>No, really, it doesn't. Nothing says the form has to be followed to this
>degree.

Well, I look at it from a automated data extraction perspective, and
little details like this make it harder to develop such tools. There
being no good reason to use "&" sometimes and "and" other times, I'd
prefer consistency, but I do agree that this is not a blocker.

>> >4.  Security Considerations
>> >
>> >    Zlib and gzip compression can be used to compress arbitrary binary
>> >    data such as hostile executable code.  Also, data that purports to be
>> >    in zlib or gzip format may not be, and fields that are supposed to be
>> >    flags, lengths, or pointers, could contain anything.  Applications
>> >    should treat any data with due scepticism.
>
>> I would prefer simply referencing the two format RFCs, the types as such
>> do not introduce additional security considerations.
>
>This may need to be reworded to make it clearer, but AFAIK the point that these
>formats decode automatically in some contexts and are therefore sometimes used
>to get hostile code past overly simplistic scans is not mentioned in those
>documents and *is* a known security concern. As such, it needs to be mentioned.

That is something the format RFCs should discuss, it's not a media type
issue. With HTTP for instance you do not have automatic decompression
based on the media type, but rather in a separate mechanism.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 22 Feb 2012 00:15:54 -0800
From: "John R. Levine" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Cleverness: None detected
Cc: Bjoern Hoehrmann <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Request for registration of application/gzip and application/zlib

>>> The draft is here:
>>>
>>> https://datatracker.ietf.org/doc/draft-levine-application-gzip/

For comments, please see the draft, not just the excepts I posted.  Most 
of Bjoern's comments are already addressed in the current draft.

R's,
John

Date: Wed, 22 Feb 2012 09:38:08 +0200
From: Gonzalo Camarillo <[email-masked]>
To: [email-masked]
Cc: Mary Barnes <[email-masked]>, Robert Sparks <[email-masked]>
Subject: [ietf-types] Review of application/media-policy-dataset+xml registration

Hi,

the draft below registers the following new media type:
media-policy-dataset+xml. Your comments on this registration are
appreciated.

Thanks,

Gonzalo

http://tools.ietf.org/html/draft-ietf-sipping-media-policy-dataset-14#section-10.1

10.1.  Media Type Registration

   Media type name: application

   Media subtype name: media-policy-dataset+xml

   Mandatory parameters: none

   Optional parameters: Same as charset parameter application/xml as
   specified in RFC 3023 [RFC3023].

   Encoding considerations: Same as encoding considerations of
   application/xml as specified in RFC 3023 [RFC3023].

   Security considerations: See Section 10 of RFC 3023 [RFC3023] and
   Section 9 of this specification.

   Interoperability considerations: none.

   Published specification: This document.

   Applications which use this media type: This document type has been
   used to convey media policy information between SIP user agents and a
   domain.

   Additional Information:

   Magic Number: None

   File Extension: .mpf or .xml

   Macintosh file type code: "TEXT"

   Personal and email address for further information: Volker Hilt,
   <[email-masked]>

   Intended usage: COMMON

   Author/Change controller: The IETF.

Date: Tue, 21 Feb 2012 23:23:07 -0800 (PST)
From: Ned Freed <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Cc: John R Levine <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Request for registration of application/gzip and	application/zlib

> * John R Levine wrote:
> >The draft is here:
> >
> >https://datatracker.ietf.org/doc/draft-levine-application-gzip/

> Thank you. The draft should mention that legacy applications have used
> application/x-gzip in the past, but that's discouraged, people should
> use the types you define instead.

> (Most of these comments apply to both types).

> >The zlib and gzip formats are defined in RFCs 1950 and 1952. This
> >defines MIME types for them.
> >
> >2.  The Application/Zlib Media Type

> I would prefer all lower-case for the type name.

> >    Type name: application
> >
> >    Subtype name: zlib
> >
> >    Required parameters: none
> >
> >    Optional parameters: none
> >
> >    Encoding considerations: needs base64 or other encoding that allows
> >    arbitrary binary data

> The value should be "8bit" (for both types).

???? These are binary formats, plain and simple. There's no encoding included
in them that would result in line-oriented output. 

I don't mind changing the wording to simply say "binary" if that is clearer,
but "8bit" is flat-out incorrect.

> >    Security considerations: See section [security] below
> >
> >    Interoperability considerations: none

> This should probably reference RFC1950.

Seems a little redundant, but whatever.

> >    Published specification: [RFC1950]
> >
> >    Applications that use this media type: anywhere data size is an issue

> Same here.

> >    Additional information:
> >
> >       Magic number(s): first byte is usually 0x78 but can also be 0x08,
> >       0x18, 0x28, 0x38, 0x48, 0x58, or 0x68.

> This is confusing.

Then suggest text. Not sure how else you can say this.

> >       File extension(s): none
> >       Macintosh file type code(s): none
> >
> >    Person and email address to contact for further information: see
> >    http://www.zlib.net/

> The form in RFC 4288 wants you to use "&" in place of "and".

No, really, it doesn't. Nothing says the form has to be followed to this
degree.

> >4.  Security Considerations
> >
> >    Zlib and gzip compression can be used to compress arbitrary binary
> >    data such as hostile executable code.  Also, data that purports to be
> >    in zlib or gzip format may not be, and fields that are supposed to be
> >    flags, lengths, or pointers, could contain anything.  Applications
> >    should treat any data with due scepticism.

> I would prefer simply referencing the two format RFCs, the types as such
> do not introduce additional security considerations.

This may need to be reworded to make it clearer, but AFAIK the point that these
formats decode automatically in some contexts and are therefore sometimes used
to get hostile code past overly simplistic scans is not mentioned in those
documents and *is* a known security concern. As such, it needs to be mentioned.

				Ned

From: Bjoern Hoehrmann <[email-masked]>
To: "John R Levine" <[email-masked]>
Date: Tue, 21 Feb 2012 21:29:47 +0100
Cc: [email-masked]
Subject: Re: [ietf-types] Request for registration of application/gzip and application/zlib

* John R Levine wrote:
>The draft is here:
>
>https://datatracker.ietf.org/doc/draft-levine-application-gzip/

Thank you. The draft should mention that legacy applications have used
application/x-gzip in the past, but that's discouraged, people should
use the types you define instead.

(Most of these comments apply to both types).

>The zlib and gzip formats are defined in RFCs 1950 and 1952. This
>defines MIME types for them.
>
>2.  The Application/Zlib Media Type

I would prefer all lower-case for the type name.

>    Type name: application
>
>    Subtype name: zlib
>
>    Required parameters: none
>
>    Optional parameters: none
>
>    Encoding considerations: needs base64 or other encoding that allows
>    arbitrary binary data

The value should be "8bit" (for both types).

>    Security considerations: See section [security] below
>
>    Interoperability considerations: none

This should probably reference RFC1950.

>    Published specification: [RFC1950]
>
>    Applications that use this media type: anywhere data size is an issue

Same here.

>    Additional information:
>
>       Magic number(s): first byte is usually 0x78 but can also be 0x08,
>       0x18, 0x28, 0x38, 0x48, 0x58, or 0x68.

This is confusing.

>       File extension(s): none
>       Macintosh file type code(s): none
>
>    Person and email address to contact for further information: see
>    http://www.zlib.net/

The form in RFC 4288 wants you to use "&" in place of "and".

>4.  Security Considerations
>
>    Zlib and gzip compression can be used to compress arbitrary binary
>    data such as hostile executable code.  Also, data that purports to be
>    in zlib or gzip format may not be, and fields that are supposed to be
>    flags, lengths, or pointers, could contain anything.  Applications
>    should treat any data with due scepticism.

I would prefer simply referencing the two format RFCs, the types as such
do not introduce additional security considerations.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: 21 Feb 2012 10:54:05 -0800
From: "John R Levine" <[email-masked]>
To: [email-masked]
Cleverness: None detected
Subject: [ietf-types] Request for registration of application/gzip and application/zlib

The draft is here:

https://datatracker.ietf.org/doc/draft-levine-application-gzip/

The zlib and gzip formats are defined in RFCs 1950 and 1952. This
defines MIME types for them.

2.  The Application/Zlib Media Type

    Type name: application

    Subtype name: zlib

    Required parameters: none

    Optional parameters: none

    Encoding considerations: needs base64 or other encoding that allows
    arbitrary binary data

    Security considerations: See section [security] below

    Interoperability considerations: none

    Published specification: [RFC1950]

    Applications that use this media type: anywhere data size is an issue

    Additional information:

       Magic number(s): first byte is usually 0x78 but can also be 0x08,
       0x18, 0x28, 0x38, 0x48, 0x58, or 0x68.
       File extension(s): none
       Macintosh file type code(s): none

    Person and email address to contact for further information: see
    http://www.zlib.net/

    Intended usage: COMMON

    Restrictions on usage: none

    Author: John Levine

    Change controller: IETF

3.  The Application/Gzip Media Type

    Type name: application

    Subtype name: gzip

    Required parameters: none

    Optional parameters: none

    Encoding considerations: needs base64 or other encoding that allows
    arbitrary binary data

    Security considerations: See section [security] below

    Interoperability considerations: none

    Published specification: [RFC1952]

    Applications that use this media type: anywhere data size is an issue

    Additional information:

       Magic number(s): first two bytes are 0x1f, 0x8b.
       File extension(s): gz
       Macintosh file type code(s): none

    Person and email address to contact for further information: see
    http://www.gzip.net/

    Intended usage: COMMON

    Restrictions on usage: none

    Author: John Levine

    Change controller: IETF

4.  Security Considerations

    Zlib and gzip compression can be used to compress arbitrary binary
    data such as hostile executable code.  Also, data that purports to be
    in zlib or gzip format may not be, and fields that are supposed to be
    flags, lengths, or pointers, could contain anything.  Applications
    should treat any data with due scepticism.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

Date: Thu, 16 Feb 2012 21:50:47 +0100
From: Mateusz Karcz <[email-masked]>
To: [email-masked]
Subject: [ietf-types] Registration of media type application/vnd.matriksoft.mfff.fragment - errata

Interoperability considerations:
 MFFF is device-, platform-, and vendor-neutral. Each program in accordance=
 with format specification can use this media type.

Date: Thu, 16 Feb 2012 21:48:28 +0100
From: Mateusz Karcz <[email-masked]>
To: [email-masked]
Subject: [ietf-types] Registration of media type application/vnd.matriksoft.mfff.fragment

Type name:
 application
Subtype name:
 vnd.matriksoft.mfff.fragment
Required parameters:
 revision <- defined in specification
Encoding considerations:
 Same as encoding considerations of application/octet-stream.
Security considerations:
 Same as security considerations of application/octet-stream and some speci=
fic for this format.
 Fragments of file linked using Matriksoft Fragmented File Format processor=
 are often small in size after downloading. However, linking output file ca=
n be huge. Before linking, the user should check the amount of available re=
sources.
Interoperability considerations:
 MFFF is device-, platform-, and vendor-neutral. Every
Matriksoft Fragmented File Format Description is also platform-neutral. Eac=
h program in accordance with format specification can use this media type.
Published specification:
 http://res.oimatriksoft.tk/spec/mfff/1.0-en.spec
Applications that use this media type:
 Each program in accordance with format specification such as Matriksoft De=
Fragmenter, can use this media type.
Additional information:
 Magic number(s): none
 File extension(s): .mff
 Macintosh file type code(s): BINA
Person & email address to contact for further information:
 Mateusz Karcz
 [email-masked]
Intended usage:
 COMMON
Restrictions on usage:
 None
Author:
 Mateusz Karcz
Change controller:
 Mateusz Karcz

Date: Tue, 14 Feb 2012 13:23:00 -0700
From: Peter Saint-Andre <[email-masked]>
To: Zach Shelby <[email-masked]>
OpenPGP: url=https://stpeter.im/stpeter.asc
Cc: [email-masked]
Subject: Re: [ietf-types] Review of application/link-format registration

<hat type='AD'/>

Note: I'll request an IETF Last Call on draft-ietf-core-link-format-11
now, which will run concurrently with the expert reviews. I am doing so
in order to get all the reviews finished before IETF 83. Just FYI!

Peter

On 2/14/12 11:47 AM, Zach Shelby wrote:
> draft-ietf-core-link-format-11 has passed WGLC in the CoRE WG. This draft has a registration for a new media type in Section 7.3 (also copied below). Your comments would be appreciated.
> 
> http://tools.ietf.org/html/draft-ietf-core-link-format-11#section-7.3
> 
> Thanks,
> Zach Shelby
> 
> 7.3.  New link-format Internet media type
> 
>    This memo registers the a new Internet media type for the CoRE link
>    format, application/link-format.
> 
>    Type name: application
> 
>    Subtype name: link-format
> 
>    Required parameters: None
> 
>    Optional parameters: None
> 
>    Encoding considerations: Binary data
> 
>    Security considerations:
> 
>    Multicast requests using CoAP for the well-known link-format
>    resources could be used to perform denial of service on a constrained
>    network.  A multicast request SHOULD only be accepted if the request
>    is sufficiently authenticated and secured using e.g.  IPsec or an
>    appropriate object security mechanism.
> 
>    CoRE link format parsers should be aware that a link description may
>    be cyclical, i.e., contain a link to itself.  These cyclical links
>    could be direct or indirect (i.e., through referenced link
>    resources).  Care should be taken when parsing link descriptions and
>    accessing cyclical links.
> 
>    Interoperability considerations:
> 
>    Published specification: [[ this document ]]
> 
>    Applications that use this media type: CoAP server and client
>    implementations for resource discovery and HTTP applications that use
>    the link-format as a payload.
> 
>    Additional information:
> 
>    Magic number(s):
> 
>    File extension(s): *.wlnk
> 
>    Macintosh file type code(s):
> 
>    Intended usage: COMMON
> 
>    Restrictions on usage: None
> 
>    Author: CoRE WG
> 
>    Change controller: IETF
> 
> 
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

From: Zach Shelby <[email-masked]>
Date: Tue, 14 Feb 2012 20:47:08 +0200
To: [email-masked]
Subject: [ietf-types] Review of application/link-format registration

draft-ietf-core-link-format-11 has passed WGLC in the CoRE WG. This =
draft has a registration for a new media type in Section 7.3 (also =
copied below). Your comments would be appreciated.

http://tools.ietf.org/html/draft-ietf-core-link-format-11#section-7.3

Thanks,
Zach Shelby

7.3.  New link-format Internet media type

   This memo registers the a new Internet media type for the CoRE link
   format, application/link-format.

   Type name: application

   Subtype name: link-format

   Required parameters: None

   Optional parameters: None

   Encoding considerations: Binary data

   Security considerations:

   Multicast requests using CoAP for the well-known link-format
   resources could be used to perform denial of service on a constrained
   network.  A multicast request SHOULD only be accepted if the request
   is sufficiently authenticated and secured using e.g.  IPsec or an
   appropriate object security mechanism.

   CoRE link format parsers should be aware that a link description may
   be cyclical, i.e., contain a link to itself.  These cyclical links
   could be direct or indirect (i.e., through referenced link
   resources).  Care should be taken when parsing link descriptions and
   accessing cyclical links.

   Interoperability considerations:

   Published specification: [[ this document ]]

   Applications that use this media type: CoAP server and client
   implementations for resource discovery and HTTP applications that use
   the link-format as a payload.

   Additional information:

   Magic number(s):

   File extension(s): *.wlnk

   Macintosh file type code(s):

   Intended usage: COMMON

   Restrictions on usage: None

   Author: CoRE WG

   Change controller: IETF

From: Paul Libbrecht <[email-masked]>
Date: Mon, 13 Feb 2012 00:23:13 +0100
To: Mateusz Karcz <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Registration of media type text/vnd.matriksoft.mfff.description+xml

--Apple-Mail-5-741958686
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Mateusz,

can you be clearer on the following:

you say:
> Intended usage:
> COMMON

so one would expect a category of applications to be applicable by this =
registration.

But you say:

> Applications that use this media type:
> Matriksoft DeFragmenter

(my intent was to figure out if media of such type would fit into the =
clipboard, I could not answer this curiosity from this line neither from =
the web-page).

... or maybe you intended to register an application-specific =
media-type?
If yes, the vnd tree is for you!

paul=

--Apple-Mail-5-741958686
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div>Mateusz,</div><div><br></div><div>can you be clearer on the =
following:</div><div><br></div><div>you say:</div><div><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Intended =
usage:<br>COMMON<br></span></blockquote></div><div><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: =
none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; =
"><br></span></div><div><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; font-family: Helvetica; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: -webkit-auto; =
text-indent: 0px; text-transform: none; white-space: normal; widows: 2; =
word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">so one would =
expect a category of applications to be applicable by this =
registration.</span></div><div><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; font-family: Helvetica; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: -webkit-auto; =
text-indent: 0px; text-transform: none; white-space: normal; widows: 2; =
word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; =
"><br></span></div><div><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; font-family: Helvetica; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: -webkit-auto; =
text-indent: 0px; text-transform: none; white-space: normal; widows: 2; =
word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">But you =
say:</span></div><div><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; font-family: Helvetica; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: -webkit-auto; =
text-indent: 0px; text-transform: none; white-space: normal; widows: 2; =
word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; =
"><br></span></div><div><blockquote type=3D"cite">Applications that use =
this media type:<br>Matriksoft =
DeFragmenter<br></blockquote><br></div>(my intent was to figure out if =
media of such type would fit into the clipboard, I could not answer this =
curiosity from this line neither from the =
web-page).<div><br></div><div>... or maybe you intended to register an =
application-specific media-type?</div><div>If yes, the vnd tree is for =
you!</div><div><br></div><div>paul</div></body></html>=

--Apple-Mail-5-741958686--

From: Bjoern Hoehrmann <[email-masked]>
To: Mateusz Karcz <[email-masked]>
Date: Sun, 12 Feb 2012 21:05:54 +0100
Cc: [email-masked]
Subject: Re: [ietf-types] Registration of media type text/vnd.matriksoft.mfff.description+xml

* Mateusz Karcz wrote:
>Type name:
> text
>Subtype name:
> vnd.matriksoft.mfff.description+xml

XML media types under the 'text' top level type are unpopular, it would
probably be a good idea to explain why this does not use 'application'.

>Required parameters:
> revision <- defined in 

Text missing.

>Optional parameters:
> charset <- Same as charset parameter of text/xml as specified in RFC 3023.
>Encoding considerations:
> Same as encoding considerations of text/xml as specified in RFC 3023.
>Security considerations:
> Same as described in RFC 3023.

This suggests there are no other considerations which is unlikely to be
the case. This should probably say something along the lines of "in
addition to ..."

>Additional information:
> Magic number(s): As specified in RFC 3023.
> File extension(s): .mfd .mffd .xml

If there are specific extensions, this should not list "xml" because it
could also be used, there would have to be more specific reasons.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Date: Sun, 12 Feb 2012 01:35:48 +0100
From: Mateusz Karcz <[email-masked]>
To: [email-masked]
Subject: [ietf-types] Registration of media type text/vnd.matriksoft.mfff.description+xml

Type name:
 text
Subtype name:
 vnd.matriksoft.mfff.description+xml
Required parameters:
 revision <- defined in=20
Optional parameters:
 charset <- Same as charset parameter of text/xml as specified in RFC 3023.
Encoding considerations:
 Same as encoding considerations of text/xml as specified in RFC 3023.
Security considerations:
 Same as described in RFC 3023.
 Fragments of file linked with Matriksoft Fragmented File Descriptions are =
often small in size after downloading. However, linking output file can be =
huge. Before linking, the user should check the amount of available resourc=
es.
Interoperability considerations:
 It's XML-based media type. XML is device-, platform-, and vendor-neutral a=
nd is supported by a wide range of Web user agents. Matriksoft Fragmented F=
ile Format Description is also platform-neutral.
Published specification:
 http://res.oimatriksoft.tk/spec/mfff/1.0-en.spec
Applications that use this media type:
 Matriksoft DeFragmenter
Additional information:
 Magic number(s): As specified in RFC 3023.
 File extension(s): .mfd .mffd .xml
 Macintosh file type code(s): TEXT
Person & email address to contact for further information:
 Mateusz Karcz
 [email-masked]
Intended usage:
 COMMON
Restrictions on usage:
 None
Author:
 Mateusz Karcz
Change controller:
 Mateusz Karcz

From: "Carl Reed" <[email-masked]>
To: "ietf types" <[email-masked]>
Date: Fri, 10 Feb 2012 13:44:07 -0700
Importance: Normal
Subject: [ietf-types] Request for review application/gml+xml - update

This is a multi-part message in MIME format.

------=_NextPart_000_019C_01CCE7FA.0F40B180
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

There was an initial flurry of dialogue on the the OGC =
application/gml+xml submission. Clemens Portele provided input in =
response to your questions. Things have been quiet for a few weeks.

I was wondering what happens next?

Thanks and regards

Carl Reed, PhD
CTO and Executive Director Standards Program
Open Geospatial Consortium
www.opengeospatial.org

The OGC: Making Location Count!

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

This communication, including attachments, is for the exclusive use of =
addressee and may contain proprietary, confidential or privileged =
information. If you are not the intended recipient, any use, copying, =
disclosure, dissemination or distribution is strictly prohibited. If you =
are not the intended recipient, please notify the sender immediately by =
return email and delete this communication and destroy all copies.

"The important thing is not to stop questioning." -- Albert Einstein=20
"Security is mostly a superstition. It does not exist in nature. Life is =
either a daring adventure or nothing." -- Helen Keller 
------=_NextPart_000_019C_01CCE7FA.0F40B180
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY dir=3Dltr>
<DIV dir=3Dltr>
<DIV style=3D"FONT-FAMILY: 'Times New Roman'; COLOR: #000000; FONT-SIZE: =
12pt">
<DIV=20
style=3D"FONT-FAMILY: 'Times New Roman'; COLOR: #000000; FONT-SIZE: =
12pt">There=20
was an initial flurry of dialogue on the the OGC application/gml+xml =
submission.=20
Clemens Portele provided input in response to your questions. Things =
have been=20
quiet for a few weeks.</DIV>
<DIV=20
style=3D"FONT-FAMILY: 'Times New Roman'; COLOR: #000000; FONT-SIZE: =
12pt">&nbsp;</DIV>
<DIV style=3D"FONT-FAMILY: 'Times New Roman'; COLOR: #000000; FONT-SIZE: =
12pt">I=20
was wondering what happens next?</DIV>
<DIV=20
style=3D"FONT-FAMILY: 'Times New Roman'; COLOR: #000000; FONT-SIZE: =
12pt">&nbsp;</DIV>
<DIV=20
style=3D"FONT-FAMILY: 'Times New Roman'; COLOR: #000000; FONT-SIZE: =
12pt">Thanks=20
and regards</DIV>
<DIV=20
style=3D"FONT-FAMILY: 'Times New Roman'; COLOR: #000000; FONT-SIZE: =
12pt">&nbsp;</DIV>
<DIV=20
style=3D"FONT-FAMILY: 'Times New Roman'; COLOR: #000000; FONT-SIZE: =
12pt">Carl=20
Reed, PhD<BR>CTO and Executive Director Standards Program<BR>Open =
Geospatial=20
Consortium<BR>www.opengeospatial.org<BR><BR>The OGC: Making Location=20
Count!<BR><BR>---------------------<BR><BR>This communication, including =

attachments, is for the exclusive use of addressee and may contain =
proprietary,=20
confidential or privileged information. If you are not the intended =
recipient,=20
any use, copying, disclosure, dissemination or distribution is strictly=20
prohibited. If you are not the intended recipient, please notify the =
sender=20
immediately by return email and delete this communication and destroy =
all=20
copies.<BR><BR>"The important thing is not to stop questioning." -- =
Albert=20
Einstein <BR>"Security is mostly a superstition. It does not exist in =
nature.=20
Life is either a daring adventure or nothing." -- Helen Keller=20
</DIV></DIV></DIV></BODY></HTML>

------=_NextPart_000_019C_01CCE7FA.0F40B180--