Sean Turner | 16 Apr 2013 17:14

[media-types] request for review: application/csrattributes

Hi media type experts,

I'd like to request a review of the application/csrattributes media type 
found in https://datatracker.ietf.org/doc/draft-ietf-pkix-est/.  The 
document is about to complete WGLC and I'd like to make sure we get the 
expert review in for the media type before we hit the IESG.

The short story: Clients query the server over HTTP to determine what if 
any additional attributes need to be included in their CSR (Certificate 
Signing Request), which is another name for PKCS#10 and CMC 
certification requests.  The server returns ASN.1 Object Identifier for 
the attributes it would like to see in the request.  All of the other 
exchanges have previously defined media types except for this one.

spt
Ali C. Begen (abegen | 20 Nov 2012 17:20
Picon
Favicon

[media-types] Registration of VP8 media subtype

Hello,

The VP8 draft is currently in WGLC in the Payload WG.
https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_text=1

The media type registration is in section 6.1.

Comments on the registration are welcome.

-acbegen
Payload WG Co-Chair
James M Snell | 5 Nov 2012 19:35
Picon
Gravatar

[media-types] draft-snell-activity-streams-type-01

Just another request for feedback before I ask for the draft to be moved along in the independent submission process... 


The draft registers the application/stream+json media type to represent JSON Activity Streams documents. It is an informational draft. The Activity Streams spec is a non-IETF produced documentation that is freely implementable.

Comments are requested and welcomed. Thank you.

- James
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
James M Snell | 11 Oct 2012 18:37
Picon
Gravatar

[media-types] New media type request: application/stream+json

Hello all, 

I would like to request the registration of a new "application/stream+json" media type [1] to represent JSON Activity Stream v1.0 document resources [2]

[1] http://www.ietf.org/id/draft-snell-activity-streams-type-01.txt

The I-D is informational as the Activity Streams specification is not an IETF-produced document. The data format is not vendor specific and is implemented in a broad range of application types. It is a proper subset of JSON so the +json suffix should be appropriate. 

- James
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Philippe Le Hegaret | 6 Sep 2012 16:19
Picon
Favicon

Registration for application/ttml+xml

Hello,

This is Appendix C of TTML 1.0.

http://www.w3.org/TR/ttaf1-dfxp/#media-type-registration

Comments on this registration would be greatly appreciated.

Type name:

        application

Subtype name:

        ttml+xml

Required parameters:

        None.

Optional parameters:
charset

        Same as application/xml media type, as specified in [XML Media
        Types] or its successors.

profile

        The document profile of a TTML document may be specified using
        an optional profile parameter, which, if specified, the value of
        which must adhere to the syntax and semantics of ttp:profile
        parameter defined by Section 6.2.8 ttp:profile of the published
        specification.

Encoding considerations:

        Same for application/xml. See [XML Media], Section 3.2.

Security considerations:

        As with other XML types and as noted in [XML Media] Section 10,
        repeated expansion of maliciously constructed XML entities can
        be used to consume large amounts of memory, which may cause XML
        processors in constrained environments to fail.

        In addition, because of the extensibility features for TTML and
        of XML in general, it is possible that "application/ttml+xml"
        may describe content that has security implications beyond those
        described here. However, if the processor follows only the
        normative semantics of the published specification, this content
        will be outside TTML namespaces and may be ignored. Only in the
        case where the processor recognizes and processes the additional
        content, or where further processing of that content is
        dispatched to other processors, would security issues
        potentially arise. And in that case, they would fall outside the
        domain of this registration document.

Interoperability considerations:

        The published specification describes processing semantics that
        dictate behavior that must be followed when dealing with, among
        other things, unrecognized elements and attributes, both in TTML
        namespaces and in other namespaces.

        Because TTML is extensible, conformant "application/ttml+xml"
        processors must expect that content received is well-formed XML,
        but it cannot be guaranteed that the content is valid to a
        particular DTD or Schema or that the processor will recognize
        all of the elements and attributes in the document.

Published specification:

        Timed Text Markup Language (TTML) 1.0.

Applications that use this media type:

        TTML is used in the television industry for the purpose of
        authoring, transcoding and exchanging timed text information and
        for delivering captions for television material repurposed for
        the internet.

        There is partial and full support of TTML in components used by
        several Web browsers plugins, and in a number of caption
        authoring tools.

Additional information:
Magic number(s):
File extension(s):

        .ttml

Macintosh file type code(s):

        "TTML"

Fragment identifiers:

        For documents labeled as application/ttml+xml, the fragment
        identifier notation is intended to be used with xml:id
        attributes, as described in section 7.2.1 of the Timed Text
        Markup Language (TTML) 1.0 specification.

Person & email address to contact for further information:

        Timed Text Working Group (public-tt <at> w3.org)

Intended usage:

        COMMON

Restrictions on usage:

        None

Author:

        The published specification is a work product of the World Wide
        Web Consortium's Timed Text (TT) Working Group.

Change controller:

        The W3C has change control over this specification.
Michael[tm] Smith | 8 Aug 2012 18:00
Picon
Favicon
Gravatar

Re: Registration for application/microdata+json

Markus Lanthaler <markus.lanthaler <at> gmx.net>, 2012-08-08 11:00 +0200:

> Michael,
> 
> I'm not sure if this is the right place to ask this question, so if it's not
> please tell me.
> I was wondering whether it was considered to use JSON-LD [1] instead of
> creating application/microdata+json. The resulting output would be more or
> less the same.

I see that you've since posted about this over on the whatwg mailing list.
I think that's the best place to discuss it, so let's see how things
progress over there.

  --Mike

--

-- 
Michael[tm] Smith http://people.w3.org/mike
Michael[tm] Smith | 7 Aug 2012 13:50
Picon
Favicon
Gravatar

Registration for application/microdata+json

This is a request to register the application/microdata+json media type by
reference to the HTML Microdata specification:

  http://www.w3.org/TR/microdata/#application-microdata-json

---------------------------------------------------------------------------
Type name:
  application

Subtype name:
  microdata+json

Required parameters:
  Same as for application/json [JSON]

Optional parameters:
  Same as for application/json [JSON]

Encoding considerations:
  8bit (always UTF-8)

Security considerations:
  Same as for application/json [JSON]

Interoperability considerations:
  Same as for application/json [JSON]

Published specification:
  Labeling a resource with the application/microdata+json type asserts that
  the resource is a JSON text that consists of an object with a single entry
  called "items" consisting of an array of entries, each of which consists of
  an object with an entry called "id" whose value is a string, an entry
  called "type" whose value is another string, and an entry called
  "properties" whose value is an object whose entries each have a value
  consisting of an array of either objects or strings, the objects being of
  the same form as the objects in the aforementioned "items" entry. Thus, the
  relevant specifications are the JSON specification and the HTML Microdata
  specification.  [JSON]

Applications that use this media type:
  Same as for application/json [JSON]

Additional information:
  Magic number(s):
    Same as for application/json [JSON]
  File extension(s):
    Same as for application/json [JSON]
  Macintosh file type code(s):
    Same as for application/json [JSON]

Person & email address to contact for further information:
  Michael[tm] Smith <mike <at> w3.org>

Intended usage:
  Common

Restrictions on usage:
  No restrictions apply.

Author:
  Ian Hickson <ian <at> hixie.ch>

Change controller:
  W3C

Fragment identifiers used with application/microdata+json resources have
the same semantics as when used with application/json (namely, at the time
of writing, no semantics at all). [JSON]
---------------------------------------------------------------------------

--

-- 
Michael[tm] Smith http://people.w3.org/mike
Michael[tm] Smith | 7 Aug 2012 13:45
Picon
Favicon
Gravatar

Registration for text/event-stream

This is a request to register the text/event-stream media type by reference
to the Server-Sent Events specification:

  http://www.w3.org/TR/eventsource/#text-event-stream

---------------------------------------------------------------------------
Type name:
  text

Subtype name:
  event-stream

Required parameters:
  No parameters

Optional parameters:
  charset
    The charset parameter may be provided. The parameter's value must be
    "utf-8". This parameter serves no purpose; it is only allowed for
    compatibility with legacy servers.

Encoding considerations:
  8bit (always UTF-8)

Security considerations:
  An event stream from an origin distinct from the origin of the content
  consuming the event stream can result in information leakage. To avoid
  this, user agents are required to apply CORS semantics. [CORS]

  Event streams can overwhelm a user agent; a user agent is expected to
  apply suitable restrictions to avoid depleting local resources because of
  an overabundance of information from an event stream.

  Servers can be overwhelmed if a situation develops in which the server is
  causing clients to reconnect rapidly. Servers should use a 5xx status
  code to indicate capacity problems, as this will prevent conforming
  clients from reconnecting automatically.

Interoperability considerations:
  Rules for processing both conforming and non-conforming content are
  defined in the Server-Sent Events specification.

Published specification:
  The Server-Sent Events specification is the relevant specification.

Applications that use this media type:
  Web browsers and tools using Web services.

Additional information:
  Magic number(s):
    No sequence of bytes can uniquely identify an event stream.

  File extension(s):
    No specific file extensions are recommended for this type.

  Macintosh file type code(s):
    No specific Macintosh file type codes are recommended for this type.

Person & email address to contact for further information:
  Michael[tm] Smith <mike <at> w3.org>

Intended usage:
  Common

Restrictions on usage:
  This format is only expected to be used by dynamic open-ended streams
  served using HTTP or a similar protocol. Finite resources are not
  expected to be labeled with this type.

Author:
  Ian Hickson <ian <at> hixie.ch>

Change controller:
  W3C

Fragment identifiers have no meaning with text/event-stream resources.
---------------------------------------------------------------------------

--

-- 
Michael[tm] Smith http://people.w3.org/mike
Michael[tm] Smith | 7 Aug 2012 13:40
Picon
Favicon
Gravatar

Registration for text/cache-manifest

This is a request to register the text/cache-manifest media type by
reference to the HTML5 specification:

  http://www.w3.org/TR/html5/iana.html#text-cache-manifest

---------------------------------------------------------------------------
Type name:
  text

Subtype name:
  cache-manifest

Required parameters:
  No parameters

Optional parameters:
  No parameters

Encoding considerations:
  8bit (always UTF-8)

Security considerations:
  Cache manifests themselves pose no immediate risk unless sensitive
  information is included within the manifest. Implementations, however,
  are required to follow specific rules when populating a cache based on a
  cache manifest, to ensure that certain origin-based restrictions are
  honored.  Failure to correctly implement these rules can result in
  information leakage, cross-site scripting attacks, and the like.

Interoperability considerations:
  Rules for processing both conforming and non-conforming content are
  defined in the HTML5 specification.

Published specification:
  The HTML5 specification is the relevant specification.

Applications that use this media type:
  Web browsers.

Additional information:
  Magic number(s):
    Cache manifests begin with the string "CACHE MANIFEST", followed by
    either a U+0020 SPACE character, a "tab" (U+0009) character, a "LF"
    (U+000A) character, or a "CR" (U+000D) character.

  File extension(s):
    "appcache"

  Macintosh file type code(s):
    No specific Macintosh file type codes are recommended for this type.

Person & email address to contact for further information:
  Michael[tm] Smith <mike <at> w3.org>

Intended usage:
  Common

Restrictions on usage:
  No restrictions apply.

Author:
  Ian Hickson <ian <at> hixie.ch>

Change controller:
  W3C

Fragment identifiers have no meaning with text/cache-manifest resources.
---------------------------------------------------------------------------

--

-- 
Michael[tm] Smith http://people.w3.org/mike
Michael[tm] Smith | 7 Aug 2012 13:36
Picon
Favicon
Gravatar

Registration for application/x-www-form-urlencoded

This is a request to register the application/x-www-form-urlencoded media
type by reference to the HTML5 specification:

  http://www.w3.org/TR/html5/iana.html#application-x-www-form-urlencoded

---------------------------------------------------------------------------
Type name:
  application

Subtype name:
  x-www-form-urlencoded

Required parameters:
  No parameters

Optional parameters:
  No parameters

Encoding considerations:
  7bit (US-ASCII encoding of octets that themselves can be encoding text
  using any ASCII-compatible character encoding)

Security considerations:
  In isolation, an application/x-www-form-urlencoded payload poses no
  security risks. However, as this type is usually used as part of a form
  submission, all the risks that apply to HTML forms need to be considered
  in the context of this type.

Interoperability considerations:
  Rules for generating and processing application/x-www-form-urlencoded
  payloads are defined in the HTML5 specification.

Published specification:
  The HTML specification is the relevant specification. Algorithms for
  encoding and decoding are defined.

Applications that use this media type:
  Web browsers and servers.

Additional information:
  Magic number(s):
    There is no reliable mechanism for recognizing
    application/x-www-form-urlencoded payloads.

  File extension(s):
    Not applicable.

  Macintosh file type code(s):
    Not applicable.

Person & email address to contact for further information:
  Michael[tm] Smith <mike <at> w3.org>

Intended usage:
  Common

Restrictions on usage:
  This type is only intended to be used to describe HTML form submission
  payloads.

Author:
  Ian Hickson <ian <at> hixie.ch>

Change controller:
  W3C

Fragment identifiers have no meaning with the application/x-www-form-urlencoded
type as this type is only used for uploaded payloads that do not have URL
identifiers.
---------------------------------------------------------------------------

--

-- 
Michael[tm] Smith http://people.w3.org/mike
Michael[tm] Smith | 7 Aug 2012 13:35
Picon
Favicon
Gravatar

Registration for multipart/x-mixed-replace

This is a request to register the multipart/x-mixed-replace media type
by reference to the HTML5 specification:

  http://www.w3.org/TR/html5/iana.html#multipart-x-mixed-replace

---------------------------------------------------------------------------
Type name:
  multipart

Subtype name:
  x-mixed-replace

Required parameters:
  boundary (defined in RFC2046) [RFC2046]

Optional parameters:
  No optional parameters.

Encoding considerations:
  binary

Security considerations:
  Subresources of a multipart/x-mixed-replace resource can be of any type,
  including types with non-trivial security implications such as text/html.

Interoperability considerations:
  None.

Published specification:
  The HTML5 specification describes processing rules for Web browsers.
  Conformance requirements for generating resources with this type are the
  same as for multipart/mixed. [RFC2046]

Applications that use this media type:
    This type is intended to be used in resources generated by Web servers,
    for consumption by Web browsers.

Additional information:
  Magic number(s):
    No sequence of bytes can uniquely identify a multipart/x-mixed-replace
    resource.

  File extension(s):
    No specific file extensions are recommended for this type.

  Macintosh file type code(s):
    No specific Macintosh file type codes are recommended for this type.

Person & email address to contact for further information:
  Michael[tm] Smith <mike <at> w3.org>

Intended usage:
  Common

Restrictions on usage:
  No restrictions apply.

Author:
  Ian Hickson <ian <at> hixie.ch>

Change controller:
  W3C

Fragment identifiers used with multipart/x-mixed-replace resources apply to
each body part as defined by the type used by that body part.
---------------------------------------------------------------------------

--

-- 
Michael[tm] Smith http://people.w3.org/mike

Gmane