Larry Masinter | 7 Apr 20:52 2016
Picon
Gravatar

updating application/pdf registration

Please review.   https://github.com/mrbhardy/pdfmime

________________________________________
From: internet-drafts <at> ietf.org <internet-drafts <at> ietf.org>
Sent: Thursday, April 7, 2016 11:28 AM
To: Larry Masinter; Dejan Markovic; Matthew Hardy; Duff Johnson; Martin Bailey
Subject: New Version Notification for draft-hardy-pdf-mime-01.txt

A new version of I-D, draft-hardy-pdf-mime-01.txt
has been successfully submitted by Larry Masinter and posted to the
IETF repository.

Name:           draft-hardy-pdf-mime
Revision:       01
Title:          The application/pdf Media Type
Document date:  2016-04-07
Group:          Individual Submission
Pages:          12
URL:            https://www.ietf.org/internet-drafts/draft-hardy-pdf-mime-01.txt
Status:         https://datatracker.ietf.org/doc/draft-hardy-pdf-mime/
Htmlized:       https://tools.ietf.org/html/draft-hardy-pdf-mime-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-hardy-pdf-mime-01

Abstract:
<1>
   The Portable Document Format (PDF) is an ISO standard (ISO
   32000-1:2008) defining a final-form document representation language
   in use for document exchange, including on the Internet, since 1993.
   This document provides an overview of the PDF format and updates the
   media type registration of "application/pdf".
(Continue reading)

John Mudge | 7 Apr 11:40 2016

Review request for structured syntax suffix registration and media type registration

Dear all,

This is a review request for:
1) Registration Request for Structured Syntax Suffix tlv
2) Media-Type Registration Request for application/vnd.oma.lwm2m+tlv

1) Registration Request for Structured Syntax Suffix tlv

Name
   Type Length Value

+suffix
   tlv

References
“Lightweight Machine to Machine Technical Specification”, OMA-TS-LightweightM2M-V1_0, http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/oma-lightweightm2m-v1-0

Direct link: http://technical.openmobilealliance.org/Technical/Release_Program/docs/LightweightM2M/V1_0-20151214-C/OMA-TS-LightweightM2M-V1_0-20151214-C.pdf


Encoding considerations
   TLV is a binary format.

Interoperability considerations
   n/a

Fragment identifier considerations
The syntax and semantics of fragment identifiers specified for +tlv SHOULD be as specified for
"application/vnd.oma.lwm2m+tlv". (At publication of this document, there is no fragment
identification syntax defined for "application/vnd.oma.lwm2m+tlv".) The syntax and semantics for
fragment identifiers for a specific "xxx/yyy+tlv" SHOULD be processed as follows: For cases defined in
+tlv, where the fragment identifier resolves per the +tlv rules, then process as specified in +tlv. For
(Continue reading)

Darrel Miller | 8 Mar 02:40 2016
Picon
Gravatar

OpenApi media type registration questions

As a member of the Technical Developer Community of the Open APIs Initiative
( https://openapis.org/governance ), I am exploring options for registering
media types for the Open API specification (previously Swagger)
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md .

Currently this document format is in its second major revision and we are
working towards a third that is likely going to have breaking changes.  The
document itself has a version property within it so there is no need for
that to appear in the media type.

There are also two distinct representations of the OpenAPI document.  One
uses the JSON format and the other uses the YAML format. It would be
desirable to distinguish between these two representations and we believe
the best approach would be to follow the precedent set by RFC 6839 and use a
+json and +yaml suffix.  As +yaml is not defined with RFC 6839 and there is
no registry defined in which to add this new suffix, I am assuming a new RFC
would be needed to register this.

As we see it, there are two different subtypes that are potentials homes for
these registrations.  There is the vendor subtree and the Standards subtree.
Considering the current support and fairly broad adoption of this format and
its new home in the Linux Foundation, I would think the standards tree would
be the more appropriate place. However, any guidance on this would be
appreciated. 

I would like to submit registrations for:

  application/openapi+json
  application/openapi+yaml

(Continue reading)

Marc Blanchet | 1 Mar 19:39 2016
Picon

media-type registration request review

Hello,
  draft-ietf-lager-specification requests the registration of a new 
media-type. The document has passed WGLC and we would like to have a 
review of the request. Herein the extract of the media-type form from 
the draft. Thanks in advance for the review

Marc, lager wg co-chair

<extract>
11.1.  Media Type Registration

    The media type "application/lgr+xml" should be registered to denote
    transmission of label generation rulesets that are compliant with
    this specification, in accordance with [RFC6838].

    Type name: application

    Subtype name: lgr+xml

    Required parameters: None.

    Optional parameters: charset (as for application/xml per [RFC7303])

    Security considerations: As for application/xml per [RFC7303]

    Interoperability considerations: As for application/xml per 
[RFC7303]

    Published specification: This document.

(Continue reading)

Picon

Request for "first come first serve" codepoint allocation for draft-ietf-idr-flowspec-redirect-ip

Dear IANA,

In support of the authors of draft-ietf-idr-flowspec-redirect-ip please find this allocation request.
The draft is in such a progressed stage that there is need to obtain a codepoint allocation 
for a new BGP transitive extended community sub-type (for both IPv4-address-specific 
or IPv6-address-specific) form the “First Come First Served” policy. 

Requesting IETF IDR WG Document:

References:

I hope to have provided the correct info and followed correctly the procedures as documented in rfc5226 and rfc7153.
Please advice on suggested next steps if this request was made incorrectly.

Kind Regards,
G/

<!-- /* Font Definitions */ <at> font-face {font-family:Arial; panose-1:2 11 6 4 2 2 2 2 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:-536859905 -1073711037 9 0 511 0;} <at> font-face {font-family:"Cambria Math"; panose-1:0 0 0 0 0 0 0 0 0 0; mso-font-charset:1; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:variable; mso-font-signature:0 0 0 0 0 0;} <at> font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:-536870145 1073786111 1 0 415 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0cm; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:Calibri; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-family:Calibri; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} <at> page WordSection1 {size:595.0pt 842.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:35.4pt; mso-footer-margin:35.4pt; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} -->

-- 

Gunter Van de Velde



_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
El-Haj-Mahmoud, Samer | 8 Feb 22:37 2016

Request to register application/efi Media Type

Type name:

application

 

Subtype name:

efi

 

Required parameters: None

 

Optional parameters:

None

 

Encoding considerations:

binary

 

Security considerations:

EFI files contains native code that executes in the pre-boot environment at the firmware privilege. Extreme caution is advised.

 

EFI files support digital signatures providing strong integrity protection using UEFI Secure Boot. Basic checksums are also supported.

 

The EFI format does not provide any confidentiality protection of its own and requires external means if that is required.

 

The EFI format does not use compression.

 

EFI files allow for runtime generation of additional code.

 

 

Interoperability considerations:

EFI binaries follow the PE-COFF standard image format, and require a UEFI compliant firmware for proper execution. The EFI file format is also dependent on the target processor architecture.

 

 

Published specification:

http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx

http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf

 

 

Applications that use this media type:

EFI compliant firmware, boot loaders, and network boot programs (NBPs) utilizing UEFI HTTP Boot.

 

Fragment identifier considerations:

None

 

Additional information:

None

 

Deprecated alias names for this type:

None

 

Magic number(s):

MZ

 

File extension(s):

*.efi

 

Macintosh file type code(s):

 

Person & email address to contact for further information:

Samer El-Haj-Mahmoud , Samer.el-haj-mahmoud <at> hpe.com

UEFI Forum , unst <at> uefi.org

 

 

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Martin J. Dürst | 3 Feb 07:41 2016
Picon
Gravatar

Re: Review request for application/geo+json media type registration

Hello Sean,

Just put want you want IANA to do into the "IANA Considerations" 
section. IANA checks all RFCs-to-be to make sure they do what's needed, 
and will come back to us if it's not clear enough.

As far as I know, there's no need to send requests separately to IANA. 
This also has the advantage that all the changes are executed in sync.

Regards,   Martin.

On 2016/02/03 14:04, Sean Gillies wrote:
> Mark,
>
> On Thu, Jan 14, 2016 at 10:04 AM, Erik Wilde <erik.wilde <at> dret.net> wrote:
>
>> hello mark.
>>
>> thanks for the feedback.
>>
>> On 2016-01-14 06:39, Mark Baker wrote:
>>
>>> I think the WG has also made enough changes
>>>> to the format (deprecation of coordinate reference systems and coordinate
>>>> position items beyond x, y, and z, for examples) to warrant a new media
>>>> type.
>>>>
>>> Well that could certainly change the balance in favour of a new type.
>>> Could you elaborate on the compatibility between the old and new
>>> formats?
>>>
>>
>> that sounds like a good idea, and
>> https://github.com/geojson/draft-geojson/issues/125 is proposing to add a
>> section explaining the changes (and that might be useful to have regardless
>> of whether there's a new media type or not). so we'll get back to you
>> shortly with a first stab of the difference between the media types.
>>
>> cheers,
>>
>> dret.
>>
>
> I'm looking for clarification on the process of deprecating
> application/vnd.geo+json (as Mike Amundsen suggested). My understanding of
> http://tools.ietf.org/html/rfc6838#section-5.5 is that I should fill out
> the http://www.iana.org/form/media-types form again, selecting Intended
> Usage: Obsolete and noting the new recommended media type for GeoJSON in
> the usage notes field, correct?
>
> Would it be desirable for draft-ietf-geojson to mention in its IANA
> Considerations that the (proposed) application/geo+json media type is to
> replace application/vnd.geo+json?
>
> Thanks for the comments above, we've incorporated them into the GeoJSON
> draft.
>
>
>
> _______________________________________________
> media-types mailing list
> media-types <at> ietf.org
> https://www.ietf.org/mailman/listinfo/media-types
>
HANSEN, TONY L | 3 Feb 14:25 2016
Picon

Re: Review request for application/geo+json media type registration

Sean,

I like the idea of documenting the differences from application/vnd.geo+json and using an IANA note saying that application/vnd.geo+json should be considered obsolete.

This should be sufficient to make the change occur in the applicatino/vnd.geo+json. Words along these lines should be fine:

IANA Considerations

The registration entry for applciation/vnd.geo+json in <http://www.iana.org/assignments/media-types/> should have its status changed to be Obsolete with a pointer to the media type application/geo+json and a reference added to this RFC.

IANA would then change the entry there to say
application/vnd.geo+json – OBSOLETED in favor of application/geo+json

If IANA wants the wording of this changed, they’ll let you know when they review your document prior to publication as an RFC.

As the change owner of record for application/vnd.geo+json, you certainly may also fill in the form at <http://www.iana.org/form/media-types> and provide the updated status as you suggested, but it shouldn’t be necessary. (Note that if you had NOT been writing an RFC about the replacement media type, then using the online form would definitely have been the proper course of action.)

Tony Hansen

From: media-types <media-types-bounces <at> ietf.org> on behalf of Sean Gillies <sean.gillies <at> gmail.com>
Date: Wednesday, February 3, 2016 at 12:04 AM
To: Mark Baker <distobj <at> acm.org>
Cc: Michael Amundsen <mamund <at> yahoo.com>, Martin Thomson <martin.thomson <at> gmail.com>, "media-types <at> iana.org" <media-types <at> iana.org>, Erik Wilde <erik.wilde <at> dret.net>
Subject: Re: [media-types] Review request for application/geo+json media type registration

Mark,

On Thu, Jan 14, 2016 at 10:04 AM, Erik Wilde <erik.wilde <at> dret.net> wrote:
hello mark.

thanks for the feedback.

On 2016-01-14 06:39, Mark Baker wrote:
I think the WG has also made enough changes
to the format (deprecation of coordinate reference systems and coordinate
position items beyond x, y, and z, for examples) to warrant a new media
type.
Well that could certainly change the balance in favour of a new type.
Could you elaborate on the compatibility between the old and new
formats?

that sounds like a good idea, and https://github.com/geojson/draft-geojson/issues/125 is proposing to add a section explaining the changes (and that might be useful to have regardless of whether there's a new media type or not). so we'll get back to you shortly with a first stab of the difference between the media types.

cheers,

dret.

I'm looking for clarification on the process of deprecating application/vnd.geo+json (as Mike Amundsen suggested). My understanding of http://tools.ietf.org/html/rfc6838#section-5.5 is that I should fill out the http://www.iana.org/form/media-types form again, selecting Intended Usage: Obsolete and noting the new recommended media type for GeoJSON in the usage notes field, correct?

Would it be desirable for draft-ietf-geojson to mention in its IANA Considerations that the (proposed) application/geo+json media type is to replace application/vnd.geo+json?

Thanks for the comments above, we've incorporated them into the GeoJSON draft.

--
Sean Gillies
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Sean Gillies | 12 Jan 06:48 2016
Picon
Gravatar

Review request for application/geo+json media type registration

Dear all,

The IETF GeoJSON WG seeks to register application/geo+json as the media type for the GeoJSON format, replacing the previously registered application/vnd.geo+json media type.

In draft-ietf-geojson-00 (https://tools.ietf.org/html/draft-ietf-geojson-00), the previously registered media type application/vnd.geo+json appears. The IANA considerations section of the next version (draft-ietf-geojson-01) will be this:

9.  IANA Considerations

   The MIME media type for GeoJSON text is application/geo+json.

   Type name: application

   Subtype name: geo+json

   Required parameters: n/a

   Optional parameters: n/a

   Encoding considerations: binary

   Security considerations: See section 5 above

   Interoperability considerations: See section 6 above

   Published specification: draft-ietf-geojson

   Applications that use this media type: various

   Additional information:

      Magic number(s) : n/a

      File extension(s) : .json, .geojson

      Macintosh file type code : TEXT

      Object Identifiers: n/a

   Person to contact for further information:

      Sean Gillies

      sean.gillies <at> gmail.com

   Intended usage: COMMON

   Restrictions on usage: none

Your comments will be gratefully appreciated.

Yours,

--
Sean Gillies
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Sean Leonard | 5 Nov 06:57 2015

Internet media type application/pkcs8-encrypted rev 2

Hello:

To keep this moving, trying a different thing. Please review.

Sean

*****

Type name: application

Subtype name: pkcs8-encrypted

Required parameters: N/A

Optional parameters:
charset: When the private key encryption algorithm incorporates a “password" that is an octet string, a
mapping between user input and the octet string is desirable. PKCS #5 [RFC2898] Section 3 recommends
"that applications follow some common text encoding rules"; it then suggests, but does not recommend,
ASCII and UTF-8. This parameter specifies the charset that a recipient SHOULD attempt first when mapping
user input to the octet string. It has the same semantics as the charset parameter from text/plain, except
that it only applies to the user’s input of the password. There is no default value.

ualg: When the charset is a Unicode-based encoding, this parameter is a space-delimited list of Unicode
algorithms that a recipient SHOULD first attempt to apply to the Unicode user input in succession, in
order to derive the octet string. The list of algorithm keywords is defined by [UNICODE]. “Tailored
operations” are operations that are sensitive to language, which must be provided as an input
parameter. If a tailored operation is called for, the exclamation mark followed by the [BCP47] language
tag specifies the language. For example, "toNFD toNFKC_Casefold!tr" first applies Normalization Form
D, followed by Normalization Form KC with Case Folding in the Turkish language, according to [UNICODE]
and [UAX31]. The default value of this parameter is empty, and leaves the matter of whether to normalize,
case fold, or apply other transformations unspecified.

Encoding considerations: binary

Security considerations:
Carries a cryptographic private key. See Section 6 of RFC 5958.
EncryptedPrivateKeyInfo PKCS #8 data contains exactly one private key. Poor password choices, weak
algorithms, or improper parameter selections (e.g., insufficient salting rounds) will make the
confidential payloads much easier to compromise.

Interoperability considerations:
PKCS #8 is a widely recognized format for private key information on all modern cryptographic stacks. The
encrypted variation in this registration, EncryptedPrivateKeyInfo (Section 3, Encrypted Private Key
Info, of RFC 5958, and Section 6 of PKCS #8), is less widely used for exchange than PKCS #12, but it is much
simpler to implement. The contents are exactly one private key (with optional attributes), so the
possibility for hidden "easter eggs" in the payload such as unexpected certificates or miscellaneous
secrets is drastically reduced.

Published specification:
PKCS #8 v1.2, November 1993 (republished as RFC 5208, May 2008); RFC 5958, August 2010

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 private key.

Fragment identifier considerations: N/A

Additional information:

Deprecated alias names for this type: N/A
Magic number(s): None.
File extension(s): .p8e
Macintosh file type code(s): N/A

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

Intended usage: COMMON

Restrictions on usage: None.

Author:
RSA, EMC, IETF

Change controller: The IETF

Provisional registration? (standards tree only): No
Attachment (smime.p7s): application/pkcs7-signature, 4831 bytes
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Sean Leonard | 16 Oct 17:35 2015

Internet media type application/pkcs8-encrypted; request review

To Media Types reviewers (and to relevant security folks):

This is a first draft of a registration request for the Internet media type application/pkcs8-encrypted,
for PKCS #8 EncryptedPrivateKeyInfo content.

Feedback is appreciated.

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

Regards,

Sean

*****

Type name: application

Subtype name: pkcs8-encrypted

Required parameters: N/A

Optional parameters: N/A

Encoding considerations: binary

Security considerations:
Carries a cryptographic private key. See Section 6 of RFC 5958.
EncryptedPrivateKeyInfo PKCS #8 data contains exactly one private key. Poor password choices, weak
algorithms, or improper parameter selections (e.g., insufficient salting rounds) will make the
confidential payloads much easier to compromise.

Interoperability considerations:
PKCS #8 is a widely recognized format for private key information on all modern cryptographic stacks. The
encrypted variation in this registration, EncryptedPrivateKeyInfo (Section 3, Encrypted Private Key
Info, of RFC 5958, and Section 6 of PKCS #8), is less widely used for exchange than PKCS #12, but it is much
simpler to implement. The contents are exactly one private key (with optional attributes), so the
possibility for hidden "easter eggs" in the payload such as unexpected certificates or miscellaneous
secrets is drastically reduced.

Published specification:
PKCS #8 v1.2, November 1993 (republished as RFC 5208, May 2008); RFC 5958, August 2010

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 private key.

Fragment identifier considerations: N/A

Additional information:

Deprecated alias names for this type: N/A
Magic number(s): None.
File extension(s): .p8e
Macintosh file type code(s): N/A

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

Intended usage: COMMON

Restrictions on usage: None.

Author:
RSA, EMC, IETF

Change controller: The IETF

Provisional registration? (standards tree only): No

Attachment (smime.p7s): application/pkcs7-signature, 5008 bytes
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types

Gmane