http://blog.gmane.org/gmane.ietf.types hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.types/1896 <pre>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 </pre> Sean Turner 2013-04-16T15:14:39 http://permalink.gmane.org/gmane.ietf.types/1895 <pre>Hello Ali, This is a standing comment of mine: Please send the actual registration template to the media-types&lt; at &gt;ietf.org list, not just a pointer to a draft (in your case not even an URI, so it's not directly "actionable"). This increases the chance of getting relevant comments significantly. Thanks and regards, Martin. On 2012/11/21 1:20, Ali C. Begen (abegen) wrote: </pre> Martin J. Dürst 2012-11-27T09:05:18 http://permalink.gmane.org/gmane.ietf.types/1894 <pre>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 </pre> Ali C. Begen (abegen 2012-11-20T16:20:28 http://permalink.gmane.org/gmane.ietf.types/1893 <pre>Just another request for feedback before I ask for the draft to be moved along in the independent submission process... http://tools.ietf.org/html/draft-snell-activity-streams-type-01 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&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/media-types </pre> James M Snell 2012-11-05T18:35:28 http://permalink.gmane.org/gmane.ietf.types/1892 <pre>Already in use in deployed applications and not my invention. On Sat, Oct 13, 2012 at 11:56 AM, Mark Nottingham &lt;mnot&lt; at &gt;mnot.net&gt; wrote: _______________________________________________ media-types mailing list media-types&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/media-types </pre> James M Snell 2012-10-13T19:01:59 http://permalink.gmane.org/gmane.ietf.types/1891 <pre>OK, never mind. On 14/10/2012, at 6:01 AM, James M Snell &lt;jasnell&lt; at &gt;gmail.com&gt; wrote: -- Mark Nottingham http://www.mnot.net/ </pre> Mark Nottingham 2012-10-13T19:02:42 http://permalink.gmane.org/gmane.ietf.types/1890 <pre>"stream" is a *really* generic word. Is this in use already? If it's not widely deployed, I'd suggest "application/activity-stream+json" or similar. Cheers, On 12/10/2012, at 3:37 AM, James M Snell &lt;jasnell&lt; at &gt;gmail.com&gt; wrote: -- Mark Nottingham http://www.mnot.net/ </pre> Mark Nottingham 2012-10-13T18:56:08 http://permalink.gmane.org/gmane.ietf.types/1889 <pre>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 [2] http://activitystrea.ms/specs/json/1.0/ 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&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/media-types </pre> James M Snell 2012-10-11T16:37:21 http://permalink.gmane.org/gmane.ietf.types/1888 <pre> Someone kindly pointed out that the version in the reference and below don't match. So here is a report of the registration template: MIME media type name: application MIME 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. Restrictions on usage: None. 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: This media type registration is extracted from Appendix C Media Type Registration of the Timed Text Markup Language (TTML) 1.0 specification. Additional information: Magic number(s): File extension(s): .ttml Macintosh file type code(s): "TTML" Macintosh Universal Type Identifier code: org.w3c.ttml conforms to public.xml Windows Clipboard Name: "Timed Text Document" Person &amp; email address to contact for further information: Timed Text Working Group (public-tt&lt; at &gt;w3.org) Intended usage: COMMON Author/Change controller: The published specification is a work product of the World Wide Web Consortium's Timed Text (TT) Working Group. The W3C has change control over this specification. </pre> Philippe Le Hegaret 2012-09-06T20:10:35 http://permalink.gmane.org/gmane.ietf.types/1887 <pre>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 &amp; email address to contact for further information: Timed Text Working Group (public-tt&lt; at &gt;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. </pre> Philippe Le Hegaret 2012-09-06T14:19:29 http://permalink.gmane.org/gmane.ietf.types/1886 <pre> It does mention this. "Labeling a resource with the text/html type asserts that the resource is an HTML document using the HTML syntax." There's no need to specify specific versions. </pre> Ian Hickson 2012-08-22T17:56:44 http://permalink.gmane.org/gmane.ietf.types/1885 <pre> I note that this one and text/cache-manifest are different with respect to charset; is there a good reason for this? Best regards, Julian </pre> Julian Reschke 2012-08-22T08:14:07 http://permalink.gmane.org/gmane.ietf.types/1884 <pre> &lt;http://tools.ietf.org/html/rfc4288#section-9&gt;: Changes should be requested only when there are serious omissions or errors in the published specification. When review is required, a change request may be denied if it renders entities that were valid under the previous definition invalid under the new definition. So it's indeed not a hard requirement. RFC 2854 indeed isn't very clear about the past versions, but that doesn't mean we shouldn't do better this time. The question here is: can I continue to label a (valid) HTML4 document which is *not* a (conforming) HTML5 document as text/html? If the answer is yes (and I'm pretty sure it is), the media type registration should mention this. (I also note that if we don't update RFC 2854 -- which would be my preference -- then we should to obsolete it) Best regards, Julian </pre> Julian Reschke 2012-08-22T07:56:49 http://permalink.gmane.org/gmane.ietf.types/1883 <pre> This is obviously not true since the current text/html registration doesn't say HTML2 is valid, instead referencing HTML4 and XHTML1. </pre> Ian Hickson 2012-08-10T17:17:50 http://permalink.gmane.org/gmane.ietf.types/1882 <pre> Understood. But media type updates are not supposed to make existing content invalid; thus the updated text/html registration needs to state that, for instance, HTML4 strict can continue to be labelled text/html. Best regards, Julian </pre> Julian Reschke 2012-08-10T10:23:29 http://permalink.gmane.org/gmane.ietf.types/1881 <pre> Aside from monitoring the main IETF list for new drafts pertaining to media types, not really. As I said, the latest update is done and about to be published. It will almost certainly be a year - and quite possibly longer - before another update is contemplated. If and when that happens there is really no way to predict when or where the discussion occur. As a practical matter, that's really not possible since existing registrations include it and so it has to be described. That said, it was relegated to an much less prominent role in the revision. Ned </pre> Ned Freed 2012-08-09T21:58:30 http://permalink.gmane.org/gmane.ietf.types/1880 <pre>Michael, Ned, Thus far, I have been monitoring the list and suggested this when it appeared to make sense. Sometimes, media-types seem to be too specific to be entering a clipboard. HTML and its cousins are clearly good candidates to live in the clipboard! Ned, is there another list I should monitor to see discussion of another round of update of this recommendation? (as indicated elsewhere, I'd also suggest that the Macintosh 4-letter type be dropped) Thanks, I have formulated this on the bug I just opened: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18508 Paul </pre> Paul Libbrecht 2012-08-09T14:44:28 http://permalink.gmane.org/gmane.ietf.types/1879 <pre>Julian Reschke &lt;julian.reschke&lt; at &gt;gmx.de&gt;, 2012-08-09 14:07 +0200: I wouldn't call that backwards-incompatible, because it only relates to validation. I take backwards-compatibility to mean that we're not breaking browser behavior for any existing content on the Web. Any elements or attributes that had browser processing/rendering behavior associated with them prior to HTML5 have that same behavior in HTML5. Document conformance and validity are a separate thing, and making that always match what HTML4 is a non-goal. --Mike </pre> Michael[tm] Smith 2012-08-09T12:27:13 http://permalink.gmane.org/gmane.ietf.types/1878 <pre> Some things that are valid HTML4 aren't conforming (valid) in HTML5 anymore. Best regards, Julian </pre> Julian Reschke 2012-08-09T12:07:36 http://permalink.gmane.org/gmane.ietf.types/1877 <pre> Either that or send the registration to IANA by email. iana&lt; at &gt;iana.org, I believe. Ned </pre> Ned Freed 2012-08-08T20:47:25 http://permalink.gmane.org/gmane.ietf.types/1876 <pre> Sure! -- Markus Lanthaler &lt; at &gt;markuslanthaler </pre> Markus Lanthaler 2012-08-08T16:09:03 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.types