Nico Williams | 14 Dec 04:29 2014

MIME type registration for "JSON text sequence" draft-ietf-json-text-sequence-11: (with DISCUSS)

   The MIME media type for JSON text sequences is application/json-seq.

   Type name: application

   Subtype name: json-seq

   Required parameters: N/A

   Optional parameters: N/A

   Encoding considerations: binary

   Security considerations: See <this document, once published>,
   Section 3.

   Interoperability considerations: Described herein.

   Published specification: <this document, once published>.

   Applications that use this media type: <by publication time
   <https://stedolan.github.io/jq> is likely to support this format>.

   Fragment identifier considerations: N/A.

   Additional information:

   o  Deprecated alias names for this type: N/A.

   o  Magic number(s): N/A

(Continue reading)

Sean Leonard | 5 Nov 01:28 2014

(arcmedia top-level media type) draft-seantek-kerwin-arcmedia-type-00.txt

Hello Colleagues:

In preparation for the arcmedia BoF, an Internet-Draft, draft-seantek-kerwin-arcmedia-type-00.txt,
has been successfully posted to the IETF repository.

This Internet-Draft was written in a hurry before the deadline, and used RFC 2077 (January 1997) as its
basis. Thus, some parts of the draft may look a bit outdated. The main purposes of this draft are to sketch
out the purpose of the archive top level media type, and to lay out several areas for further discussion and work.

(This Internet-Draft actually posted last week, but there was a naming snag.)

Name:		draft-seantek-kerwin-arcmedia-type
Revision:	00
Title:		Concise Binary Object Representation (CBOR) Tags for ASN.1 Object Identifiers
Document date:	2014-10-27
Group:		Individual Submission
Pages:		10
URL:            http://www.ietf.org/internet-drafts/draft-seantek-kerwin-arcmedia-type-00.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-kerwin-arcmedia-type-00/
Htmlized:       http://tools.ietf.org/html/draft-seantek-kerwin-arcmedia-type-00

Abstract:
  This document defines a new primary content-type to be known as
  "archive", which defines a fundamental type of content with unique
  presentational, hardware, and processing aspects.

The IETF Secretariat

-Sean
Attachment (smime.p7s): application/pkcs7-signature, 6521 bytes
(Continue reading)

Sean Leonard | 28 Oct 01:54 2014

New Version Notification for draft-seantek-text-nfo-00.txt

media-types and apps-discuss Colleagues:

An Internet-Draft to register text/nfo has been posted. text/x-nfo is currently in use.

NFO refers to Relase iNFOrmation. 

Feedback welcome.

Regards,

Sean

Begin forwarded message:

> From: internet-drafts <at> ietf.org
> Subject: New Version Notification for draft-seantek-text-nfo-00.txt
> Date: October 27, 2014 at 7:45:00 AM PDT

A new version of I-D, draft-seantek-text-nfo-00.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-text-nfo
Revision:	00
Title:		The text/nfo Media Type
Document date:	2014-10-24
Group:		Individual Submission
Pages:		11
URL:            http://www.ietf.org/internet-drafts/draft-seantek-text-nfo-00.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-text-nfo/
(Continue reading)

Sean Leonard | 23 Oct 12:15 2014

New Version Notification for draft-seantek-image-bmp-01.txt

Colleagues:

draft-seantek-image-bmp-01 has been posted. It removes the problematic sentence about not containing text.

Note that there are embedded questions in the introduction: shall the .cur and .ani formats also be
registered? And shall the .ico format be re-registered? (.cur is almost identical to .ico; .ani, not so much.)

Here is the registration template:
*******
Windows Bitmap Media Type Registration Application

   Type name: image

   Subtype name: bmp

   Required parameters: None.

   Optional parameters: None.

   Encoding considerations: Binary.

   Security considerations:

     Bitmaps have a mostly unremarkable security history.

     Because BMP data can encapsulate JPEG or PNG data (BI_JPEG, BI_PNG
     values of the Compression enumeration in Section 2.1.1.7 of [MS-
     WMF]), the security considerations of JPEG and PNG processing may
     also apply to BMP.

(Continue reading)

internet-drafts | 17 Oct 19:40 2014
Picon

New Version Notification for draft-seantek-image-wmf-emf-00.txt

Colleagues:

An Internet-Draft to register image/wmf and image/emf has been posted.

Thanks to Alexey Melnikov and Dave Thaler, who provided advice on these drafts prior to submission.

Feedback welcome.

Regards,

Sean

*******************
A new version of I-D, draft-seantek-image-wmf-emf-00.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-image-wmf-emf
Revision:	00
Title:		The Windows Metafile and Enhanced Metafile Media Types
Document date:	2014-10-17
Group:		Individual Submission
Pages:		8
URL:            http://www.ietf.org/internet-drafts/draft-seantek-image-wmf-emf-00.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-image-wmf-emf/
Htmlized:       http://tools.ietf.org/html/draft-seantek-image-wmf-emf-00

Abstract:
  This document registers the image/wmf and image/emf media types for
  use with Windows Metafile and Enhanced Metafile formats. Originally
(Continue reading)

Sean Leonard | 17 Oct 20:17 2014

image/bmp: New Version Notification for draft-seantek-image-bmp-00.txt

Colleagues:

An Internet-Draft to register image/bmp has been posted.

Thanks to Alexey Melnikov and Dave Thaler, who provided advice on these drafts prior to submission.

Feedback welcome.

Regards,

Sean

*******************
A new version of I-D, draft-seantek-image-bmp-00.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-image-bmp
Revision:	00
Title:		The Windows Bitmap Media Type
Document date:	2014-10-17
Group:		Individual Submission
Pages:		5
URL:            http://www.ietf.org/internet-drafts/draft-seantek-image-bmp-00.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-image-bmp/
Htmlized:       http://tools.ietf.org/html/draft-seantek-image-bmp-00

Abstract:
  This document registers the image/bmp media type for use with the
  Windows Bitmap format (BMP), also known as Device-Independent Bitmap
(Continue reading)

Sean Leonard | 17 Oct 20:08 2014

image/wmf and image/emf: New Version Notification for draft-seantek-image-wmf-emf-00.txt

Colleagues:

An Internet-Draft to register image/wmf and image/emf has been posted.

Thanks to Alexey Melnikov and Dave Thaler, who provided advice on these drafts prior to submission.

Feedback welcome.

Regards,

Sean

*******************
A new version of I-D, draft-seantek-image-wmf-emf-00.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-image-wmf-emf
Revision:	00
Title:		The Windows Metafile and Enhanced Metafile Media Types
Document date:	2014-10-17
Group:		Individual Submission
Pages:		8
URL:            http://www.ietf.org/internet-drafts/draft-seantek-image-wmf-emf-00.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-image-wmf-emf/
Htmlized:       http://tools.ietf.org/html/draft-seantek-image-wmf-emf-00

Abstract:
 This document registers the image/wmf and image/emf media types for
 use with Windows Metafile and Enhanced Metafile formats. Originally
(Continue reading)

Stian Soiland-Reyes | 14 Oct 03:07 2014
Picon

Fwd: "Cool" Linked Data URIs for all IANA mediatypes?

tl;dr: Ensure every registered media type has a corresponding URI,
avoid 404 for http://www.iana.org/assignments/media-types/text/plain

In Linked Data [1][2] we need identifiers for common resources. These
identifiers are typically so-called "Cool URIs" [3].

Internet Media Types are commonly referred to when describing resource
metadata, particularly in the case of packaging or redistributing
resources.

Many newer mediatypes have individual pages at iana, like:

  http://www.iana.org/assignments/media-types/application/pdf

Put many mediatypes do not have such a "cool URI", e.g.

  http://www.iana.org/assignments/media-types/text/plain
  404 Not Found

I therefore feel that as a third-party I am not at liberty to "invent"
such URIs by simply appending the registered (or unregistered!) type
to an URI template

  http://www.iana.org/assignments/media-types/{type}/{subtype}

Additionally there is no RDF information available for media-types
using content-negotiation at iana.org - some of the URIs give HTML,
other plain text.

Some third-party efforts have been made to create alternative URIs to
(Continue reading)

Kathleen Moriarty | 1 Oct 19:12 2014
Picon

Review request for draft-ietf-oauth-json-web-token-27

Hello,

I'd like to request a media-type registration review for draft-ietf-oauth-json-web-token-27, Section 10.3.

--

Best regards,
Kathleen
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Sean Leonard | 25 Sep 01:23 2014

A proposal for a new top-level media type: archive

Colleagues on media-types and apps-discuss:

I would like to propose that the IETF create a new top-level media type: 
archive.

Basically, archive would be a top-level type for all types of archive 
formats.
https://en.wikipedia.org/wiki/Archive_file
https://en.wikipedia.org/wiki/List_of_archive_formats

I think it's important to register archive formats as a distinct type 
from application, because there are common semantics that apply. In 
fact, these semantics are very similar to multipart and message 
top-level types.

The archive data types are all storage formats for *files*, as opposed 
to *content*. Each file has its own security implications, along with 
metadata that also has security implications (user and group 
permissions, access bits, executable bits, ACLs). At the highest level, 
an Internet-connected application ought to be able to identify that a 
particular piece of content is of this type (as opposed to the opaque 
application type), so it can make decisions about the content that are 
unique to archives, namely, dealing with the security issues, and 
presenting uniform user interfaces to handling such archives. Content 
bundling types like message (RFC 5322), multipart, and application/cms 
(CMS) are conceptually distinct. All those types can contain content 
that can get split off into files, but their purpose is not to replicate 
file system data.

Archives are ubiquitous on the Internet. Even if archives are used 
"infrequently" across the Internet architecture, they are obviously used 
at the endpoints. Improper transmission of archives has become a major 
source of labeling and security issues.

Remarkably, most archive formats have not been registered as media types 
(except for application/zip, which is an oldie). Therefore, it's pretty 
much a "clean field". Furthermore, there is a trend of a lot of widely 
available tools to support multiple formats, so the probability is good 
that if you pass some archive/* labeled content to an archive 
application, it will be able to do something intelligent with it.

The following major sub-types of archives, all belong in a common 
top-level media type: [from Wikipedia]
* archiving only (concatenate files): tar
*  multi-function (concatenate, compress, encrypt, etc.): zip, rar, 7z, 
arc, arj, the list goes on and on...
* software packaging: cab, msi, pup, pet, apk, rpm...
* disk image: ISO-9660 (CD/DVD/Blu-Ray), Apple Disk Image, virtual 
floppy disks, formerly-known-as-TrueCrypt, etc.
* backup: (a large quantity of proprietary formats)

I know that the TLMT matter has been brought up before with fonts. 
<http://www6.ietf.org/mail-archive/web/apps-discuss/current/msg03447.html>

Where do we start? Maybe we should talk about it? I don't think it's as 
simple as drafting an Internet-Draft. Maybe there should be a BOF or 
working group. Experts with file system and archival experience should 
get involved.

Sean
Sean Leonard | 22 Sep 04:43 2014

Can we please bring media type registrations into the 21st century--Mac File Type codes

While looking over the registrations, I noticed that it is required to 
provide Mac OS File Type codes.

That is all well and good, but Mac OS File Type codes are so 1993. I 
mean, literally **1993**. Mac OS X has been using Uniform Type 
Identifiers since 2001.

How do people feel about updating the registration template to include 
Apple Uniform Type Identifiers, and hopefully also to remove Mac File 
Type codes?

Thanks,

Sean

Gmane