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
Sean Leonard | 22 Sep 04:36 2014

Re: Internet media type application/tar; request review

On 9/19/2014 10:25 PM, "Martin J. Dürst" wrote:
> On 2014/09/20 03:22, Sean Leonard wrote:
>> To Media Types reviewers:
>>
>> This is a first draft of a registration request for the Internet media
>> type application/tar, for tar format archives.
>
>> Registration Template [DRAFT]
>>
>> Type name: application
>>
>> Subtype name: tar
>>
>> Required parameters: N/A
>>
>> Optional parameters: N/A
>
> I think these should be "None", because N/A suggests "don't know"
>
> Regards,   Martin.

Ok.

Draft 2:

Registration Template [DRAFT]

Type name: application

Subtype name: tar

Required parameters: None.

Optional parameters: None.

Encoding considerations: binary

Security considerations:
TAR (Tape ARchive), as an archive format, can contain arbitrary files of
arbitrary types, including files that are not considered "regular files" 
(e.g., symbolic links, directories). Some of these files may be 
executable or contain executable data,
including scripts, that could compromise the security of a computer. 
Additionally, some files may contain directives such as URIs that, when 
accessed, can compromise privacy. As POSIX file system
information can be recorded in this format, user and group permissions,
dates, and the like can also be overwritten when the data is extracted. 
Furthermore, when encoding data in this format, personal data such as 
user and group permissions from a source computer system can be
surreptitiously included in the format as a method of exfiltrating that 
data. The format permits extensions ("pax extensions")--these extensions 
may have their own security risks.

Interoperability considerations:
TAR is a widely-recognized archive format on all modern computer 
systems, especially those relating to UNIX and the POSIX standards. The 
format has undergone several iterations; the main current variations are 
"pax" and "ustar", which are compatible with each other.

Published specification:
POSIX.1-2008, IEEE Std 1003.1-2008 (2013 Edition), IEEE Standard for 
Information Technology - Portable Operating System Interface (POSIX)" 
Shell and Utilities - pax - EXTENDED DESCRIPTION - pax Interchange 
Format, ustar Interchange Format

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html

Applications that use this media type:
pax is the POSIX utility. Most UNIX-compatible implementations also 
include a utility called tar.
Most software archiving programs of any notoriety process this format; 
implementations are too numerous to list.

Fragment identifier considerations: N/A

Additional information:

  Deprecated alias names for this type: N/A
  Magic number(s): hex: 75 73 74 61 72 00 30 30, aka
                   US-ASCII: u s t a r NUL 0 0,
                   at octet 257
  File extension(s): tar
  Macintosh file type code(s): N/A

Person & email address to contact for further information:
  Sean Leonard <dev+ietf <at> seantek.com>
  Andrew Josey <ogdirector-platform <at> opengroup.org>

Intended usage: COMMON

Restrictions on usage: None.

Author:
The Austin Common Standards Revision Group (CSRG)
The Institute of Electrical and Electronics Engineers (IEEE)
The Open Group

Change controller: CSRG <ogdirector-platform <at> opengroup.org>

Provisional registration? (standards tree only): No

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types

Gmane