Ken Kwan | 24 Jun 21:41 2015

Vendor-Specific Media Type: PagerDuty

Hello,

PagerDuty would like to register a vendor-specific media type. As per https://tools.ietf.org/html/rfc4288#section-3.2:
"While public exposure and review of media types to be registered in the vendor tree is not required, using the ietf-types <at> iana.org mailing list for review is strongly encouraged to improve the quality of those specifications."

Please let me know if there should be any modifications before directly submitting to IANA.

Thanks,
Kenneth Kwan


Name: Kenneth Kwan
  1. Media Type Name: application
  2. Subtype name: Vendor Tree - vnd.pagerduty+json
  3. Required parameters: None
  4. Optional parameters: version=[version string, e.g. “1.0”]
  5. Encoding considerations: 7 bit text
  6. Security considerations: the security issues associated with this type have not been assessed
  7. Interoperability considerations: None
  8. Published specification: None
  9. Applications which use this media type: PagerDuty API (developer.pagerduty.com)
  10. Fragment identifier considerations: None
  11. Restrictions on usage: None
  12. Provisional registration? (standards tree only): N/A
  13. Additional information: N/A
    1. Deprecated alias names for this type: N/A
    2. Magic number(s): N/A
    3. File extension(s): N/A
    4. Macintosh File Type Code(s): N/A
    5. Object Identifier(s) or OID(s): N/A
  14. Intended usage: (Common) Used by clients to indicate that the request is in PagerDuty's API-specified format and is expecting a formatted response as per the API definition (as described at https://developer.pagerduty.com).
  15. Other Information/General Comment (optional): N/A
  16. Person to contact for further information
    1. Name: Steve Rice
    2. E-mail: developers <at> pagerduty.com
    3. Author/Change controller: Steve Rice, developers <at> pagerduty.com
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Ivan Herman | 4 May 21:42 2015
Picon

Review request for the application/csvm+json media type registration

Dear all,

The W3C CSV on the Web Working Group plans to publish a Last Call Candidate Recommendation of the Metadata
Vocabulary for Tabular Data specification in June 2015.

We would be grateful for your feedback on the Media Type section of the specification:

Latest published version: 
	http://www.w3.org/TR/tabular-metadata/#iana-considerations
Latest editors' draft, includes some comments on the IANA considerations' section:
	http://w3c.github.io/csvw/metadata/index.html#iana-considerations

Text version of the latest version is included below; the security considerations' section has also been
copied here in text format.

We look forward to hearing your comments,

Best regards,

Ivan Herman
W3C staff contact for the CSV on the Web Working Group
http://www.w3.org/People/Ivan/

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

Type name:
    application

Subtype name:
    csvm+json

Required parameters:
    N/A

Optional parameters:
    N/A

Encoding considerations:
    Binary, as per [RFC6839], section 3.1; the charset parameter is not used and byte-order marks are not
permitted, as per [RFC7159], sections 11 and 8.1

Security considerations:
    See [RFC7159] section 12 and section 7. Security Considerations of this specification (see copy below)

Interoperability considerations:
    Note that this format is not the same as the existing text/csv and text/tab-delimited-values mediatypes,
but a JSON-based format used to annotate such documents. Also see [RFC7159] for interoperability
information for JSON.

Published specification:
    This specification.

Applications that use this media type:
    It is anticipated that there is a broad need for data validators and converters to alternate structured
representations of tabular data. It is expected that many applications and programming languages will
be using this media type across many operating systems.

Fragment identifier considerations:
    See [RFC6839], section 3.1

Additional information:
    Magic number(s):
        n/a
    File extension(s):
        ".json"
    Macintosh file type code(s):
        "TEXT"
    Macintosh Universal Type Identifier code:
        org.w3c.csvm conforms to public.json
    Windows Clipboard Name
        Tabular Metadata in JSON

Person & email address to contact for further information:
    Ivan Herman <ivan <at> w3.org>

Intended usage:
    COMMON

Restrictions on usage:
    None

Author/Change controller:
    The Tabular metadata specification is the product of the CSV on the Web Working Group. The W3C reserves
change control over this specification.

-----

Security Considerations

Applications that process tabular data may use that data to drive other actions, which may have security
implications. These behaviors are outside the scope of this specification.

Third party metadata provided about a tabular data file (such as a CSV file) may rename or ignore headers, or
exclude rows or columns, which may lead to data being misinterpreted by applications that process it.

Transformation definitions are a possible security risk as they enable the creators of metadata to
reference arbitrary code that may be executed to convert tabular data into other formats.
Implementations should run this arbitrary code in a sandboxed environment to reduce the security risk. 
Murray S. Kucherawy | 14 Apr 21:25 2015
Picon

Early review request: draft-ietf-appsawg-text-markdown

Hi there,

Could we get an early review of this document?  It contains a media type registration.  The document is approaching Working Group Last Call in APPSAWG and I wanted to see if there's anything he should fix before the formal request comes through.

https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/

It's a good opportunity for me to train on filtering new requests too.

Thanks,
-MSK
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
mike amundsen | 2 Mar 18:42 2015
Picon

Fwd: New Version Notification for draft-amundsen-richardson-foster-alps-01.txt

The updated I-D for ALPS was just posted it to the IETF tracker (see details below). I've also updated the web site[0] . 

We're looking for any/all comments and feedback. Feel free to discuss on the ALPS list[1] or here, and to open/update issues in github[2] for the next round of changes. 



---------- Forwarded message ----------
From: <internet-drafts <at> ietf.org>
Date: Mon, Mar 2, 2015 at 12:23 PM
Subject: New Version Notification for draft-amundsen-richardson-foster-alps-01.txt
To: Mike Amundsen <mca <at> amundsen.com>, Leonard Richardson <leonardr <at> segfault.org>, "Mark W. Foster" <mwf <at> fosrias.com>



A new version of I-D, draft-amundsen-richardson-foster-alps-01.txt
has been successfully submitted by Mike Amundsen and posted to the
IETF repository.

Name:           draft-amundsen-richardson-foster-alps
Revision:       01
Title:          Application-Level Profile Semantics (ALPS)
Document date:  2015-02-28
Group:          Individual Submission
Pages:          27
URL:            http://www.ietf.org/internet-drafts/draft-amundsen-richardson-foster-alps-01.txt
Status:         https://datatracker.ietf.org/doc/draft-amundsen-richardson-foster-alps/
Htmlized:       http://tools.ietf.org/html/draft-amundsen-richardson-foster-alps-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-amundsen-richardson-foster-alps-01

Abstract:
   This document describes ALPS, a data format for defining simple
   descriptions of application-level semantics, similar in complexity to
   HTML microformats.  An ALPS document can be used as a profile to
   explain the application semantics of a document with an application-
   agnostic media type (such as HTML, HAL, Collection+JSON, Siren,
   etc.).  This increases the reusability of profile documents across
   media types.

Editorial Note (To be removed by RFC Editor)

   Distribution of this document is unlimited.  Comments should be sent
   to the IETF Media-Types mailing list (see [1]).




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Michael[tm] Smith | 18 Feb 05:50 2015
Picon

View pending media-type applications?

Is there still no public Web‐based interface to view details of media‐type
applications that have been submitted via http://www.iana.org/form/media-types
but not approved yet?

  ーMike

--

-- 
Michael[tm] Smith https://people.w3.org/mike
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Ali C. Begen (abegen | 31 Dec 05:46 2014
Picon

Registration for the Opus media subtype (draft-ietf-payload-rtp-opus-05)

Hello

The following draft is in the WGLC process. It registers a media subtype for the Opus codec. The
registration is in Section 6 and below.
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/?include_text=1

If you have comments, please provide them.

Thanks and happy new year.
Ali C. Begen (Payload Co-chair)

6.1.  Opus Media Type Registration

   Media type registration is done according to [RFC6838] and [RFC4855].

   Type name: audio

   Subtype name: opus

   Required parameters:

   rate:  the RTP timestamp is incremented with a 48000 Hz clock rate
      for all modes of Opus and all sampling rates.  For data encoded
      with sampling rates other than 48000 Hz, the sampling rate has to
      be adjusted to 48000 Hz.

   Optional parameters:

   maxplaybackrate:  a hint about the maximum output sampling rate that
      the receiver is capable of rendering in Hz.  The decoder MUST be
      capable of decoding any audio bandwidth but due to hardware
      limitations only signals up to the specified sampling rate can be
      played back.  Sending signals with higher audio bandwidth results
      in higher than necessary network usage and encoding complexity, so
      an encoder SHOULD NOT encode frequencies above the audio bandwidth
      specified by maxplaybackrate.  This parameter can take any value
      between 8000 and 48000, although commonly the value will match one
      of the Opus bandwidths (Table 1).  By default, the receiver is
      assumed to have no limitations, i.e. 48000.

   sprop-maxcapturerate:  a hint about the maximum input sampling rate
      that the sender is likely to produce.  This is not a guarantee
      that the sender will never send any higher bandwidth (e.g. it
      could send a pre-recorded prompt that uses a higher bandwidth),
      but it indicates to the receiver that frequencies above this
      maximum can safely be discarded.  This parameter is useful to
      avoid wasting receiver resources by operating the audio processing
      pipeline (e.g. echo cancellation) at a higher rate than necessary.
      This parameter can take any value between 8000 and 48000, although
      commonly the value will match one of the Opus bandwidths
      (Table 1).  By default, the sender is assumed to have no
      limitations, i.e. 48000.

   maxptime:  the maximum duration of media represented by a packet
      (according to Section 6 of [RFC4566]) that a decoder wants to
      receive, in milliseconds rounded up to the next full integer
      value.  Possible values are 3, 5, 10, 20, 40, 60, or an arbitrary
      multiple of an Opus frame size rounded up to the next full integer
      value, up to a maximum value of 120, as defined in Section 4.  If
      no value is specified, the default is 120.

   ptime:  the preferred duration of media represented by a packet
      (according to Section 6 of [RFC4566]) that a decoder wants to
      receive, in milliseconds rounded up to the next full integer
      value.  Possible values are 3, 5, 10, 20, 40, 60, or an arbitrary
      multiple of an Opus frame size rounded up to the next full integer
      value, up to a maximum value of 120, as defined in Section 4.  If
      no value is specified, the default is 20.

   stereo:  specifies whether the decoder prefers receiving stereo or
      mono signals.  Possible values are 1 and 0 where 1 specifies that
      stereo signals are preferred, and 0 specifies that only mono
      signals are preferred.  Independent of the stereo parameter every
      receiver MUST be able to receive and decode stereo signals but
      sending stereo signals to a receiver that signaled a preference
      for mono signals may result in higher than necessary network
      utilization and encoding complexity.  If no value is specified,
      the default is 0 (mono).

   sprop-stereo:  specifies whether the sender is likely to produce
      stereo audio.  Possible values are 1 and 0, where 1 specifies that
      stereo signals are likely to be sent, and 0 specifies that the
      sender will likely only send mono.  This is not a guarantee that
      the sender will never send stereo audio (e.g. it could send a pre-
      recorded prompt that uses stereo), but it indicates to the
      receiver that the received signal can be safely downmixed to mono.
      This parameter is useful to avoid wasting receiver resources by
      operating the audio processing pipeline (e.g. echo cancellation)
      in stereo when not necessary.  If no value is specified, the
      default is 0 (mono).

   cbr:  specifies if the decoder prefers the use of a constant bitrate
      versus variable bitrate.  Possible values are 1 and 0, where 1
      specifies constant bitrate and 0 specifies variable bitrate.  If
      no value is specified, the default is 0 (vbr).  When cbr is 1, the
      maximum average bitrate can still change, e.g. to adapt to
      changing network conditions.

   useinbandfec:  specifies that the decoder has the capability to take
      advantage of the Opus in-band FEC.  Possible values are 1 and 0.
      Providing 0 when FEC cannot be used on the receiving side is
      RECOMMENDED.  If no value is specified, useinbandfec is assumed to
      be 0.  This parameter is only a preference and the receiver MUST
      be able to process packets that include FEC information, even if
      it means the FEC part is discarded.

   usedtx:  specifies if the decoder prefers the use of DTX.  Possible
      values are 1 and 0.  If no value is specified, the default is 0.

   Encoding considerations:

      The Opus media type is framed and consists of binary data
      according to Section 4.8 in [RFC6838].

   Security considerations:
   See Section 7 of this document.

   Interoperability considerations: none

   Published specification: none

   Applications that use this media type:

      Any application that requires the transport of speech or audio
      data can use this media type.  Some examples are, but not limited
      to, audio and video conferencing, Voice over IP, media streaming.

   Person & email address to contact for further information:

      SILK Support silksupport <at> skype.net
      Jean-Marc Valin jmvalin <at> jmvalin.ca

   Intended usage: COMMON

   Restrictions on usage:

      For transfer over RTP, the RTP payload format (Section 4 of this
      document) SHALL be used.

   Author:

      Julian Spittka jspittka <at> gmail.com

      Koen Vos koenvos74 <at> gmail.com

      Jean-Marc Valin jmvalin <at> jmvalin.ca

   Change controller: TBD
Sean Leonard | 29 Dec 11:36 2014

Internet media type application/pkcs12; request review

To Media Types reviewers (et. al.):

This is a first draft of a registration request for the Internet media 
type application/pkcs12, for PKCS #12 content.

Per RFC 6838, I do not believe that this registration requires a formal 
RFC since it is from a recognized standards organization (IETF itself). 
Feedback is appreciated.

This registration is consistent with the recent application/pkcs8 and 
application/pkcs10 registrations. The relevant standard, RFC 7292, is 
primarily a republication of PKCS #12, and does not have its own media 
type registration in the text.

Regards,

Sean

*******

Registration Template [DRAFT]

Type name: application

Subtype name: pkcs12

Required parameters: N/A

Optional parameters: N/A

Encoding considerations: binary

Security considerations:
PKCS #12 data typically contains one or more private keys encrypted with 
a password using a key derivation function. Poor password choices, weak 
algorithms, or improper parameter selections (e.g., insufficient salting 
rounds) will make the confidential payloads much easier to compromise. 
Additionally, PFX was subject to criticism for being too obtuse and 
cumbersome to implement (see Gutmann, P., PFX - How Not to Design a 
Crypto Protocol/Standard, 
<https://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html>). Many of these 
(editorial) shortcomings have been addressed in the latest publications 
of PKCS #12.

Interoperability considerations:
PKCS #12 (formerly PFX, Personal Information Exchange) is a widely 
recognized format for exchange of secret (personal identity) information 
on all modern cryptographic stacks. The format is primarily used for the 
exchange of private keys and certificates, but can also be used to 
exchange symmetric keys, miscellaneous secrets, attributed objects, and 
extensions.

Published specification:
PKCS #12 v1.0, June 1999; PKCS #12 v1.1 (RFC 7292), July 2014

Applications that use this media type:

Machines, applications, browsers, Internet kiosks, and so on, that support this standard allow a user to
import, export, and exercise a single set of personal identity information.

Fragment identifier considerations: N/A

Additional information:

  Deprecated alias names for this type: N/A
  Magic number(s): 30h at octet 0
  File extension(s): .p12, .pfx
  Macintosh file type code(s): N/A

Person & email address to contact for further information:
  Sean Leonard <dev+ietf <at> seantek.com>

Intended usage: COMMON

Restrictions on usage: None.

Author:
(originally Microsoft), RSA, EMC, IETF

Change controller: The IESG (?)

Provisional registration? (standards tree only): No
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

   o  File extension(s): N/A.

   o  Macintosh file type code(s): N/A.

   o  Person & email address to contact for further information:

      *  json <at> ietf.org

   o  Intended usage: COMMON

   o  Author: See the "Authors' Addresses" section of this document.

   o  Change controller: IETF
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
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
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/
Htmlized:       http://tools.ietf.org/html/draft-seantek-text-nfo-00

Abstract:
  This document registers the text/nfo media type for use with release
  iNFOrmation. While mostly compatible with text/plain, ".NFO" files
  and content have unique encoding and rendering characteristics that
  make them distinguishable from typical plain text.

The IETF Secretariat

************
2. Release iNFOrmation Media Type Registration Application

   Type name: text

   Subtype name: nfo

   Required parameters:

    charset: Per Section 4.2.1 of [RFC6838], charset is REQUIRED. Unlike
     most other text types, the default value is the character set of
     the original IBM PC and MS-DOS, called OEM Code Page 437. For
     purposes of this Internet-Draft, the parameter value is "~oem437".
     [[TODO: figure this out.]] Implementations MUST support OEM Code
     Page 437. Unfortunately, the simple application of the IANA
     registered character set "IBM437" (aka "cp437") [RFC1345] will miss
     some important characters, so conformant implementations MUST
     support OEM Code Page 437 as specified in Section 3. NFOs authored
     for more modern computing environments are known to use ISO-8859-1,
     ISO-8859-15 (including support for the Euro sign), or UTF-8;
     however, for maximum interoperability, these or any other character
     sets MUST be declared by the sender. When absent, a receiver MAY
     guess, but SHOULD heavily bias the outcome towards OEM Code Page
     437 unless UTF-8 encoding is patently obvious. A RECOMMENDED
     detection algorithm is provided in Appendix A.

   Optional parameters:

    baud: A natural number (integer greater than 0) indicating the gross
     bit rate at which the NFO is supposed to be rendered to screen.
     This optional parameter provides a nostalgic effect from the days
     of modems and fixed-speed serial lines. It also controls the
     animation rate, to the extent that the NFO employs optional escape
     sequences.

   Encoding considerations:

     Text with 8-bit code points; all 8-bit combinations (including
     perhaps NUL) are possible. Accordingly, text SHOULD be quoted-
     printable or base64 encoded when transmitted over a channel that is
     not 8-bit clean.

   Security considerations:

     None; it's just text. The ANSI escape sequence "CSI 5 m" could,
     however, blink you to death.

   Interoperability considerations:

     NFOs are plain text but look best when read in a terminal view or
     with a dedicated NFO viewer that can emulate terminal features. As
     a result, they SHOULD be treated differently than text/plain files.
     The reference implementation that all NFO viewers SHOULD target is
     an IBM PC-compatible machine running MS-DOS 6.22 with the ANSI.SYS
     MS-DOS device driver loaded, where the NFO is displayed as if it
     were output to the terminal using the "TYPE" command.

   Published specification: This specification.

   Applications that use this media type:

     NFO viewers; text editors; terminals.

   Fragment identifier considerations:

     Same as text/plain [RFC5147]. Note that escape sequences do not
     contribute to the character count [[NB: do they?]], and line breaks
     are treated as one character, regardless of whether CRLF or some
     other code(s) are used.

   Additional information:

     Deprecated alias names for this type: text/x-nfo
     File extension(s): .nfo
     Macintosh file type code(s):
       TEXT. A uniform type identifier (UTI) of "????", which conforms
       to "public.plain-text", is RECOMMENDED.

   Person & email address to contact for further information:

     Sean Leonard <dev+ietf <at> seantek.com>

   Restrictions on usage: None.

   Author/Change controller: Sean Leonard <dev+ietf <at> seantek.com>

   Intended usage: COMMON

   Provisional registration? No
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.

   Interoperability considerations:

     Uncompressed Windows Bitmaps can be rather large. If there is a
     need to compress an image, modern applications SHOULD consider
     emitting JPEG or PNG data instead of embedding them in BMP
     payloads.

   Published specification: [MS-WMF] and [BMPSTOR].

   Applications that use this media type:

     Office productivity applications; clip art applications; desktop
     publishing applications; Web browsers; graphics processing
     applications.

   Fragment identifier considerations: None.

   Additional information:

     Magic number(s): 42 4D ("BM"), meaning "bitmap". The next
                      field (BITMAPFILEHEADER bfSize) is a
                      little-endian DWORD indicating the size
                      of the bitmap content in bytes.
     File extension(s): .bmp, .dib
     Macintosh file type code(s):
       "BMP ", "BMPf", or "BMPp". Apple has promulgated a
       uniform type identifier (UTI) of "com.microsoft.bmp".

   Person & email address to contact for further information:

     Sean Leonard <dev+ietf <at> seantek.com>

   Restrictions on usage: None.

   Author/Change controller: Sean Leonard <dev+ietf <at> seantek.com>

   Intended usage: COMMON

   Provisional registration? No

*******

Begin forwarded message:

> From: internet-drafts <at> ietf.org
> Subject: New Version Notification for draft-seantek-image-bmp-01.txt
> Date: October 23, 2014 at 3:06:50 AM PDT
> To: Sean Leonard <dev+ietf <at> seantek.com>, "Sean Leonard" <dev+ietf <at> seantek.com>
> 
> 
> A new version of I-D, draft-seantek-image-bmp-01.txt
> has been successfully submitted by Sean Leonard and posted to the
> IETF repository.
> 
> Name:		draft-seantek-image-bmp
> Revision:	01
> Title:		The Windows Bitmap Media Type
> Document date:	2014-10-23
> Group:		Individual Submission
> Pages:		5
> URL:            http://www.ietf.org/internet-drafts/draft-seantek-image-bmp-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-seantek-image-bmp/
> Htmlized:       http://tools.ietf.org/html/draft-seantek-image-bmp-01
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-seantek-image-bmp-01
> 
> Abstract:
>   This document registers the image/bmp media type for use with the
>   Windows Bitmap format (BMP), also known as Device-Independent Bitmap
>   (DIB). Originally designed for Microsoft Windows 2.0 and OS/2, these
>   bitmaps contain a single raster graphic in a variety of compressed or
>   uncompressed formats.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

Gmane