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
Sean Leonard | 5 Oct 02:37 2015

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

A new version of the Independent Submission for the media type text/nfo is posted; comments welcome.

Per IETF policies, the media type registration template is provided below for the sake of media-types <at>  ;
the charset registration template is provided below for the sake of ietf-charsets <at>  .

(Note that the last time that I submitted the template to ietf-charsets <at>  on September 5, 2015, I got a bounce
back. Not good.)

Sean

Begin forwarded message:

> From: internet-drafts <at> ietf.org
> Subject: New Version Notification for draft-seantek-text-nfo-02.txt
> Date: October 4, 2015 at 5:29:52 PM PDT
> 

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

Name:		draft-seantek-text-nfo
Revision:	02
Title:		The text/nfo Media Type
Document date:	2015-10-04
Group:		Individual Submission
Pages:		13
URL:            https://www.ietf.org/internet-drafts/draft-seantek-text-nfo-02.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-text-nfo/
Htmlized:       https://tools.ietf.org/html/draft-seantek-text-nfo-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-seantek-text-nfo-02

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.

*****
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, and named
     "oem437". 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 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: 

     It's just text; this format provides no facilities for
     confidentiality or integrity. The ANSI escape sequence "CSI 5 m"
     could, however, blink you to death. As only a subset of ANSI escape
     sequences MUST be interpreted; interpreting a greater range than
     the subset prescribed in this registration may introduce other
     security issues, such as transmitting operating system commands.

     Some code points in oem437 have been used ambiguously in practice,
     so implementations SHOULD NOT assume that the mapping between this
     charset and Unicode is bijective. When displayed, codes 00, 20, and
     FF MAY appear to be similar, i.e., as a blank space.

   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: [[Note to RFC Editor: Insert number here.]]

   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 "public.nfo", 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

*****
     To: ietf-charsets <at> iana.org
     Subject: Registration of new charset oem437

     Charset name: oem437

     Charset aliases: None.

     Suitability for use in MIME text: Suitable.

     Published specification(s): This specification; [OEMCP437].

     ISO 10646 equivalency table:

       This table is taken from the IBM437 registration in [RFC1345],
       with modifications based on actual implementations of [OEMCP437],
       as discussed in this document. Character mnemonic symbols
       generally map to the Unicode code points listed in Section 3
       of [RFC1345], with the following exceptions. The symbol suffix
       $ (for example, HT$) means that the Unicode code point
       mapping is essentially correct, but an implementation might
       need to perform additional or special processing as discussed
       in this document, depending on the output environment.
       The symbol $$ means that this code point has special
       considerations as discussed in this document, so no
       single, definitive Unicode code point mapping can be given.
       Finally, three characters have no corresponding mnemonic
       symbols in Section 3 of [RFC1345], so symbols are defined here:

         $>   25ba   BLACK RIGHT-POINTING POINTER
         $<   25c4   BLACK LEFT-POINTING POINTER
         $B   21a8   UP DOWN ARROW WITH BASE

       NU$ 0u 0U cH- cD- cC cS BL$ BS$ HT$ LF$ Ml Fm CR$ M2 SU
       $> $< UD !*2 PI SE SR $B -! -v $$ EC$ -L <> UT Dt
       SP !  "  Nb DO %  &  '  (  )  *  +  ,  -  .  /
       0  1  2  3  4  5  6  7  8  9  :  ;  <  =  >  ?
       At A  B  C  D  E  F  G  H  I  J  K  L  M  N  O
       P  Q  R  S  T  U  V  W  X  Y  Z  <( // )> '> _
       '! a  b  c  d  e  f  g  h  i  j  k  l  m  n  o
       p  q  r  s  t  u  v  w  x  y  z  (! !! !) '? Eh
       C, u: e' a> a: a! aa c, e> e: e! i: i> i! A: AA
       E' ae AE o> o: o! u> u! y: O: U: Ct Pd Ye Pt Fl
       a' i' o' u' n? N? -a -o ?I NI NO 12 14 !I << >>
       .S :S ?S vv vl vL Vl Dl dL VL VV LD UL Ul uL dl
       ur uh dh vr hh vh vR Vr UR DR UH DH VR HH VH uH
       Uh dH Dh Ur uR dR Dr Vh vH ul dr FB LB lB RB TB
       a* $$ G* $$ $$ s* $$ t* F* H* $$ $$ 00 $$ $$ (U
       =3 +- >= =< Iu Il -: ?2 Ob .M Sb RT nS 2S fS NS$

     Additional information:

       See this document for details on how to handle particular codes
       that correspond both to graphemes in the IBM PC ROM, and
       to control characters.

     Person & email address to contact for further information:

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

     Intended usage: COMMON

*END*

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
Thomas Edwards | 2 Oct 20:11 2015

Query regarding SMPTE Media Type registration

[Note: I am speaking for myself, and not officially for SMPTE]

RFC 6838 states that a Media Type in the Standards Tree can be "registered by a recognized standards-related organization using the 'Specification Required' IANA registration policy [RFC5226] (which implies Expert Review)."  My impression is that this means a discussion of the registration on this list, before submission to http://www.iana.org/form/media-types

Is the Society of Motion Picture and Television Engineers (SMPTE) considered a "recognized standards-related organization" by the IETF for this purpose?

(I will mention that SMPTE is an ANSI Accredited Standards Developer, and has previously registered a Media Type via RFC 4539, but there are RTP payloads defined by SMPTE Standards that are not documented by RFCs that may be appropriate for Media Type registration).

Thanks!

-Thomas

-- 
Thomas Edwards
VP Engineering & Development
FOX Networks Engineering and Operations
thomas.edwards <at> fox.com

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Ben Harris | 15 Jul 19:53 2015
Picon
Picon

Re: Proposed media type registration for YAML

On Tue, 14 Jul 2015, Chris Rebert wrote:

> (My apologies for replying off-list like this. I wasn't yet a
> subscriber when you posted your message, so I can't reply to it
> on-list properly. However, feel free to publicly reference or quote
> from this reply.)
>
> Based on YAML's entry in the de facto *nix MIME types database
> (http://cgit.freedesktop.org/xdg/shared-mime-info/tree/freedesktop.org.xml.in
> ), you might consider including the following among the list of
> deprecated aliases:
>
> * application/x-yaml
>
> * text/yaml
> * text/x-yaml

Thanks.  I'll add them.  While they're listed as "YAML document", I doubt 
the author was considering the technical distinction between a YAML 
document and a YAML stream when writing that.

--

-- 
Ben Harris, University of Cambridge Information Services.
Ben Harris | 7 Jul 16:33 2015
Picon
Picon

Proposed media type registration for YAML

Below is a media type registration I'm proposing to submit for YAML.  I 
have one specific question for the list:

* Is it appropriate to use a "text/*" type for something that might be 
encoded in UTF-16 or UTF-32?  I'm confident that YAML in UTF-8 fits the 
line-break requirements of RFC 2046, but I'm not sure whether that permits 
UTF-16 or UTF-32.

    Type name:

text

    Subtype name:

vnd.yaml

    Required parameters:

None

    Optional parameters:

There is a single optional parameter, "version", whose value MUST match 
the ns-yaml-version production in YAML 1.1 or YAML 1.2.  If provided, it 
identifies a version of the YAML specification to which the corresponding 
entity conforms.

The "charset" parameter is not used: The YAML specifications define how a 
YAML processor should determine whether a YAML stream is encoded in UTF-8, 
UTF-16, or UTF-32.

    Encoding considerations:

binary

    Security considerations:

Interpreting arbitrary YAML can be dangerous.  Many YAML processors are 
able to serialise and deserialise arbitrary objects in their host 
programming language, which can include arbitrary executable code. 
Applications consuming YAML from untrusted sources MUST restrict the range 
of object types that can be deserialised to those that are safe.

YAML allows for the construction of complex data structures, including 
cyclic ones.  This can create structures that simple reference-counting 
garbage collectors cannot collect when they become unreferenced.  YAML 
consumers using such garbage collectors may need to record which 
references were generated using aliases and to break those references 
before allowing the structure to become unreferenced.

    Interoperability considerations:

N/A

    Published specification:

YAML Ain’t Markup Language (YAML™) Version 1.2, 
http://yaml.org/spec/1.2/spec.html
YAML Ain’t Markup Language (YAML™) Version 1.1, http://yaml.org/spec/1.1/
YAML Ain't Markup Language (YAML™) 1.0, http://yaml.org/spec/1.0/

In each case, a text/vnd.yaml entity is a complete YAML stream, which 
might potentially contain multiple YAML documents.

    Applications that use this media type:

A wide variety of implementations are listed at <http://yaml.org>.

    Fragment identifier considerations:

Fragment identifiers are reserved for future standardisation.  While 
having them refer to YAML anchor names is tempting, those are deliberately 
not unique within a stream and hence would not make good fragment 
identifiers.

    Additional information:

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

    Person & email address to contact for further information:

YAML mailing list <yaml-core <at> lists.sourceforge.net>

    Intended usage:

COMMON

    Restrictions on usage:

N/A

    Author:

Ben Harris, University of Cambridge <bjh21 <at> cam.ac.uk>

    Change controller:

Ben Harris, University of Cambridge <bjh21 <at> cam.ac.uk>
on behalf of Oren Ben-Kiki <oren <at> ben-kiki.org>, Clark Evans 
<cce <at> clarkevans.com>, and Ingy döt Net <ingy <at> ingy.net>

    Provisional registration? (standards tree only):

N/A

--

-- 
Ben Harris, University of Cambridge Information Services.
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
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

Gmane