Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F86221F8630 for ; Wed, 22 Aug 2012 10:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h12k9gLtXwS2 for ; Wed, 22 Aug 2012 10:56:46 -0700 (PDT) Received: from homiemail-a51.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by ietfa.amsl.com (Postfix) with ESMTP id E989B21F862B for ; Wed, 22 Aug 2012 10:56:45 -0700 (PDT) Received: from homiemail-a51.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a51.g.dreamhost.com (Postfix) with ESMTP id 3E7392E8058; Wed, 22 Aug 2012 10:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=AyAdFP839gCXZP5ZiHBInMq4oaI=; b=Rf+ OKOAZ1xqUJ9D2rPQiqtyGg+5kLuxlF3vWBkPlhLgv4zGENeTuRWyWOClG6Vi9pLF WyjvF7ZAB7PGUBQWtiiSBa/v2dd8oQm6WoiNjlA8k3Ej40kjWOOYgKtYPyW7nilv Ey0pg3eI28AIoyIr5wMjdDsPy84QeHwqn/93w90A= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a51.g.dreamhost.com (Postfix) with ESMTPSA id 1F5552E8057; Wed, 22 Aug 2012 10:56:45 -0700 (PDT) Date: Wed, 22 Aug 2012 17:56:44 +0000 (UTC) From: Ian Hickson To: Julian Reschke In-Reply-To: <503490C1.6090304@gmx.de> Message-ID: References: <20120807111647.GB67292@sideshowbarker> <20120807172840.GH68105@sideshowbarker> <5023A808.8090007@gmx.de> <20120809122712.GP71263@sideshowbarker> <5024E121.9020906@gmx.de> <503490C1.6090304@gmx.de> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Update to text/html registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 17:56:46 -0000 On Wed, 22 Aug 2012, Julian Reschke wrote: > > 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. 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. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B2E21F860E for ; Wed, 22 Aug 2012 01:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NA8Uc3mbdHn for ; Wed, 22 Aug 2012 01:14:14 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id BDE0521F8577 for ; Wed, 22 Aug 2012 01:14:13 -0700 (PDT) Received: (qmail invoked by alias); 22 Aug 2012 08:14:12 -0000 Received: from unknown (EHLO [172.24.113.24]) [192.147.117.12] by mail.gmx.net (mp017) with SMTP; 22 Aug 2012 10:14:12 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18BcUQ7wxEBpc33MgWQ3wXn9MLw6PmtquOR9aXy9C 83GH1PHFOhVd2w Message-ID: <503494CF.2000402@gmx.de> Date: Wed, 22 Aug 2012 10:14:07 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Michael[tm] Smith" References: <20120807114550.GJ67292@sideshowbarker> In-Reply-To: <20120807114550.GJ67292@sideshowbarker> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Registration for text/event-stream X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 08:14:15 -0000 On 2012-08-07 13:45, Michael[tm] Smith wrote: > 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. > ... 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 Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E3621F867E for ; Wed, 22 Aug 2012 00:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.488 X-Spam-Level: X-Spam-Status: No, score=-103.488 tagged_above=-999 required=5 tests=[AWL=-0.889, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+gyOWpwKkXU for ; Wed, 22 Aug 2012 00:56:51 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 74C0821F867A for ; Wed, 22 Aug 2012 00:56:51 -0700 (PDT) Received: (qmail invoked by alias); 22 Aug 2012 07:56:50 -0000 Received: from unknown (EHLO [172.24.113.24]) [192.147.117.12] by mail.gmx.net (mp002) with SMTP; 22 Aug 2012 09:56:50 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX182EY0oCfk2pW76NKx6BEzsmD/Nmf18apnhvpQKS2 1UDVdt+Nabi7w1 Message-ID: <503490C1.6090304@gmx.de> Date: Wed, 22 Aug 2012 09:56:49 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Ian Hickson References: <20120807111647.GB67292@sideshowbarker> <20120807172840.GH68105@sideshowbarker> <5023A808.8090007@gmx.de> <20120809122712.GP71263@sideshowbarker> <5024E121.9020906@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Update to text/html registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 07:56:56 -0000 On 2012-08-10 19:17, Ian Hickson wrote: > On Fri, 10 Aug 2012, Julian Reschke wrote: >> >> 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. > > This is obviously not true since the current text/html registration > doesn't say HTML2 is valid, instead referencing HTML4 and XHTML1. : 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 Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFF821F8645 for ; Fri, 10 Aug 2012 10:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEPrzJ-ZpV5r for ; Fri, 10 Aug 2012 10:17:51 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2E42B21F855E for ; Fri, 10 Aug 2012 10:17:51 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 97B9412C0C5; Fri, 10 Aug 2012 10:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=piRjRzBiw/UZohZFOJo4YVxud38=; b=obO aOGsTOFnJ5UbSxCJoMZxaoiKT6geFgptT2PtFVVsbhicyaXrBeqRktzOWKHsQpLv b7p51XRrg6Hm48pNNhMMug5FwYC8g495iYYpRPJX4rxdrpJH2PdFCA8QS+h8kY7+ FHrgHBmyvi4iH6Gs1UQh/m8M218YyJ9/Ag2Iyg6o= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 915CC12C0C1; Fri, 10 Aug 2012 10:17:50 -0700 (PDT) Date: Fri, 10 Aug 2012 17:17:50 +0000 (UTC) From: Ian Hickson To: Julian Reschke In-Reply-To: <5024E121.9020906@gmx.de> Message-ID: References: <20120807111647.GB67292@sideshowbarker> <20120807172840.GH68105@sideshowbarker> <5023A808.8090007@gmx.de> <20120809122712.GP71263@sideshowbarker> <5024E121.9020906@gmx.de> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Update to text/html registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 17:17:51 -0000 On Fri, 10 Aug 2012, Julian Reschke wrote: > > 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. This is obviously not true since the current text/html registration doesn't say HTML2 is valid, instead referencing HTML4 and XHTML1. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDA021F863B for ; Fri, 10 Aug 2012 03:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.985 X-Spam-Level: X-Spam-Status: No, score=-105.985 tagged_above=-999 required=5 tests=[AWL=-3.386, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWGDPjTjqdaS for ; Fri, 10 Aug 2012 03:23:59 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 0927E21F8539 for ; Fri, 10 Aug 2012 03:23:58 -0700 (PDT) Received: (qmail invoked by alias); 10 Aug 2012 10:23:57 -0000 Received: from AMontpellier-259-1-40-245.w92-133.abo.wanadoo.fr (EHLO [192.168.3.131]) [92.133.19.245] by mail.gmx.net (mp010) with SMTP; 10 Aug 2012 12:23:57 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19JVSRoADRJ4TW19O0qwAoBJF8qouTdSylxlC/yAP k+QpD4uKKmLTI7 Message-ID: <5024E121.9020906@gmx.de> Date: Fri, 10 Aug 2012 12:23:29 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Thunderbird/16.0a2 MIME-Version: 1.0 To: "Michael[tm] Smith" References: <20120807111647.GB67292@sideshowbarker> <20120807172840.GH68105@sideshowbarker> <5023A808.8090007@gmx.de> <20120809122712.GP71263@sideshowbarker> In-Reply-To: <20120809122712.GP71263@sideshowbarker> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Update to text/html registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 10:24:00 -0000 On 09.08.2012 14:27, Michael[tm] Smith wrote: > Julian Reschke , 2012-08-09 14:07 +0200: > >> On 07.08.2012 19:28, Michael[tm] Smith wrote: >>> Mark Baker , 2012-08-07 10:00 -0400: >>>> I left the WG when HTML5 was deliberately backwards-incompatible, >>> >>> Not sure what in particular you thought was deliberately backwards- >>> incompatible, but OK. >> >> Some things that are valid HTML4 aren't conforming (valid) in HTML5 anymore. > > 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. 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 Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0616421F86AD for ; Thu, 9 Aug 2012 15:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=1.071, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeTj776vEqKW for ; Thu, 9 Aug 2012 15:10:24 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE0621F8606 for ; Thu, 9 Aug 2012 15:10:24 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIUQ7ML9DS006FS2@mauve.mrochek.com> for ietf-types@ietf.org; Thu, 9 Aug 2012 15:05:21 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Thu, 9 Aug 2012 15:05:17 -0700 (PDT) Message-id: <01OIUQ7JWQXY0006TF@mauve.mrochek.com> Date: Thu, 09 Aug 2012 14:58:30 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 09 Aug 2012 16:44:28 +0200" <416304E6-3651-4237-9526-D1AC8FEDDEF4@hoplahup.net> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120807111647.GB67292@sideshowbarker> <20120807171420.GG68105@sideshowbarker> <01OIRYFYVNZK0006TF@mauve.mrochek.com> <416304E6-3651-4237-9526-D1AC8FEDDEF4@hoplahup.net> To: Paul Libbrecht Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Update to text/html registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 22:10:25 -0000 > Michael, Ned, > >> Are those important just for HTML and XHTML, or are there other formats > >> which would benefit from having those defined as part of their > >> registrations? > > > > They probably are. > 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! > >> If those would be useful or other formats, I'd suggest the guidelines for > >> media-type registrations be updated to suggest including them for all > >> registrations. > > > > I'm afraid it is a little late for that. The media types registration > > were just updated. Had this been proposed during the updating process (which > > took over a years), I can pretty much guarantee it would have been included, > > but the document is now final and it's too late. > Ned, is there another list I should monitor to see discussion of another > round of update of this recommendation? 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 indicated elsewhere, I'd also suggest that the Macintosh 4-letter type be > dropped) 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 Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B6021F865E for ; Thu, 9 Aug 2012 07:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.63 X-Spam-Level: X-Spam-Status: No, score=-3.63 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCU-ngIJgSBT for ; Thu, 9 Aug 2012 07:45:49 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id CE75221F8652 for ; Thu, 9 Aug 2012 07:45:48 -0700 (PDT) Received: from [192.168.1.185] (ip-109-84-0-72.web.vodafone.de [109.84.0.72]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MKbX5-1SzkqD45bT-001cKs; Thu, 09 Aug 2012 16:45:39 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Libbrecht In-Reply-To: <01OIRYFYVNZK0006TF@mauve.mrochek.com> Date: Thu, 9 Aug 2012 16:44:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <416304E6-3651-4237-9526-D1AC8FEDDEF4@hoplahup.net> References: <20120807111647.GB67292@sideshowbarker> <20120807171420.GG68105@sideshowbarker> <01OIRYFYVNZK0006TF@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:4i81qLUgbzpolOfq0gVZfaCGM2Ej17UugHUo/cwkKIe hsr45J9tY7IsKotjp+WFcMfwDbjALG4JBdVmT+SV0Fy/38GRFk pZ2XjvGkhrxQbHepqqYM+z52TJ91sMz0s4A/wvVVMAmkz4+uSC UsLybOOg3dP49/iVUrspLOR0qrbFPBKYPlWPtPeovLDlgsvBEt G5IhJ/8f8eyVsDMbp7hwTpKmAO87edPQ2zcs1yX89wNiD5px3A jguSaI8kzo+IdH3ooOqP6ICxs8/pkqduiLEiE3ZuzE4N6bAL6/ wWY2os2s6+z+UjLqInCqZ2EgPltuPvijbHUsyJwCqDErDuatfG nvZ2xPuPYLYgKIsA4JkfunTywCqSSKzaBGFOXPPJWksG8O/VKL uwo80Ric+1xLQ== Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Update to text/html registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 14:45:49 -0000 Michael, Ned, >> Are those important just for HTML and XHTML, or are there other = formats >> which would benefit from having those defined as part of their >> registrations? >=20 > They probably are. 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! >> If those would be useful or other formats, I'd suggest the guidelines = for >> media-type registrations be updated to suggest including them for all >> registrations. >=20 > I'm afraid it is a little late for that. The media types registration > were just updated. Had this been proposed during the updating process = (which > took over a years), I can pretty much guarantee it would have been = included, > but the document is now final and it's too late. 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) > My suggestion would be to put these in the additional information = section. Thanks, I have formulated this on the bug I just opened: https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D18508 Paul= Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD6421F86B0 for ; Thu, 9 Aug 2012 05:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.491 X-Spam-Level: X-Spam-Status: No, score=-10.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00Ot3mB-Coro for ; Thu, 9 Aug 2012 05:27:16 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 8196A21F86A1 for ; Thu, 9 Aug 2012 05:27:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=MikeSmith.local) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1SzRpb-00077P-1r; Thu, 09 Aug 2012 08:27:15 -0400 Date: Thu, 9 Aug 2012 21:27:13 +0900 From: "Michael[tm] Smith" To: Julian Reschke Message-ID: <20120809122712.GP71263@sideshowbarker> References: <20120807111647.GB67292@sideshowbarker> <20120807172840.GH68105@sideshowbarker> <5023A808.8090007@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5023A808.8090007@gmx.de> User-Agent: Mutt/0488deb39a35+poontang (2012-05-24 22:02:57+09:00) Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Update to text/html registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 12:27:17 -0000 Julian Reschke , 2012-08-09 14:07 +0200: > On 07.08.2012 19:28, Michael[tm] Smith wrote: > >Mark Baker , 2012-08-07 10:00 -0400: > >>I left the WG when HTML5 was deliberately backwards-incompatible, > > > >Not sure what in particular you thought was deliberately backwards- > >incompatible, but OK. > > Some things that are valid HTML4 aren't conforming (valid) in HTML5 anymore. 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 -- Michael[tm] Smith http://people.w3.org/mike Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1C421F8658 for ; Thu, 9 Aug 2012 05:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uzGk5GyJyZh for ; Thu, 9 Aug 2012 05:08:16 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D23EA21F86A8 for ; Thu, 9 Aug 2012 05:08:15 -0700 (PDT) Received: (qmail invoked by alias); 09 Aug 2012 12:08:09 -0000 Received: from AMontpellier-554-1-173-121.w86-202.abo.wanadoo.fr (EHLO [192.168.3.132]) [86.202.44.121] by mail.gmx.net (mp041) with SMTP; 09 Aug 2012 14:08:09 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+9WxZS3Ci9G3Gi3ydIjxMoP6Cq/VZJZwo+YB+Ab/ 9XNdlAMYv+Juya Message-ID: <5023A808.8090007@gmx.de> Date: Thu, 09 Aug 2012 14:07:36 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Thunderbird/16.0a2 MIME-Version: 1.0 To: ietf-types@ietf.org References: <20120807111647.GB67292@sideshowbarker> <20120807172840.GH68105@sideshowbarker> In-Reply-To: <20120807172840.GH68105@sideshowbarker> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: [ietf-types] Update to text/html registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 12:08:18 -0000 On 07.08.2012 19:28, Michael[tm] Smith wrote: > Mark Baker , 2012-08-07 10:00 -0400: > >> Hi Mike, >> >> I left the WG when HTML5 was deliberately backwards-incompatible, > > Not sure what in particular you thought was deliberately backwards- > incompatible, but OK. Some things that are valid HTML4 aren't conforming (valid) in HTML5 anymore. Best regards, Julian Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18EE21F862B for ; Wed, 8 Aug 2012 13:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWyy+zVyv8nw for ; Wed, 8 Aug 2012 13:53:11 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E649721F8622 for ; Wed, 8 Aug 2012 13:53:10 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIT97HLTI80023MI@mauve.mrochek.com> for ietf-types@ietf.org; Wed, 8 Aug 2012 13:48:05 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Wed, 8 Aug 2012 13:47:59 -0700 (PDT) Message-id: <01OIT97DVH5C0006TF@mauve.mrochek.com> Date: Wed, 08 Aug 2012 13:47:25 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 08 Aug 2012 21:53:35 +0900" <20120808125333.GH68705@sideshowbarker> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120807111647.GB67292@sideshowbarker> <01OISEPVDL760006TF@mauve.mrochek.com> <20120808125333.GH68705@sideshowbarker> To: "Michael[tm] Smith" Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Update to text/html registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 20:53:12 -0000 > Ned Freed , 2012-08-07 23:06 -0700: > > I should also point out that ietf-types is a review list only, and note that > > posting stuff here does NOT make it a formal update request. Under the newly > > adopted rules, that has to be done by submitting the update request to IANA. > > > > You may already be aware of this, but I given the wording of the messages I > > thought it was a good idea to point it out. > Actually I wasn't aware of it :-) But that explains a few things. > So to be clear: Is the correct procedure now to use the > http://www.iana.org/cgi-bin/mediatypes.pl form? Either that or send the registration to IANA by email. iana@iana.org, I believe. Ned Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FC121F8716 for ; Wed, 8 Aug 2012 09:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gltpj5BatiG8 for ; Wed, 8 Aug 2012 09:09:07 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 0DA3E21F8711 for ; Wed, 8 Aug 2012 09:09:06 -0700 (PDT) Received: (qmail invoked by alias); 08 Aug 2012 16:09:05 -0000 Received: from host31-108-dynamic.17-79-r.retail.telecomitalia.it (EHLO Vostro3500) [79.17.108.31] by mail.gmx.net (mp012) with SMTP; 08 Aug 2012 18:09:05 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1+sE5QtNJasEwpuZuUWRgcGWtvjS7t93KlEKLRrWZ nKsFD/ZIjGiC/f From: "Markus Lanthaler" To: "'Michael[tm] Smith'" References: <20120807115025.GK67292@sideshowbarker> <00c901cd7544$44c8d210$ce5a7630$@lanthaler@gmx.net> <20120808160045.GE70332@sideshowbarker> In-Reply-To: <20120808160045.GE70332@sideshowbarker> Date: Wed, 8 Aug 2012 18:09:03 +0200 Message-ID: <014601cd7580$21f217b0$65d64710$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac11fvwhco5pLIwKSXeWoQR5Y9AP5gAAR+Sg Content-Language: de X-Y-GMX-Trusted: 0 Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Registration for application/microdata+json X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:09:08 -0000 Michael[tm] Smith wrote: > 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. Sure! -- Markus Lanthaler @markuslanthaler Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F259E21F86B7 for ; Wed, 8 Aug 2012 09:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.482 X-Spam-Level: X-Spam-Status: No, score=-10.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqcqYvTWpmt5 for ; Wed, 8 Aug 2012 09:00:51 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 68B2621F86B6 for ; Wed, 8 Aug 2012 09:00:51 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=MikeSmith.local) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Sz8gj-0002v3-Ul; Wed, 08 Aug 2012 12:00:50 -0400 Date: Thu, 9 Aug 2012 01:00:47 +0900 From: "Michael[tm] Smith" To: Markus Lanthaler Message-ID: <20120808160045.GE70332@sideshowbarker> References: <20120807115025.GK67292@sideshowbarker> <00c901cd7544$44c8d210$ce5a7630$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00c901cd7544$44c8d210$ce5a7630$@lanthaler@gmx.net> User-Agent: Mutt/0488deb39a35+poontang (2012-05-24 22:02:57+09:00) Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Registration for application/microdata+json X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:00:52 -0000 Markus Lanthaler , 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 Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E24921F8600 for ; Wed, 8 Aug 2012 05:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.471 X-Spam-Level: X-Spam-Status: No, score=-10.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSUX66ZoFkRf for ; Wed, 8 Aug 2012 05:53:38 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id D32BC21F85ED for ; Wed, 8 Aug 2012 05:53:38 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=MikeSmith.local) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Sz5lZ-0007an-4t; Wed, 08 Aug 2012 08:53:37 -0400 Date: Wed, 8 Aug 2012 21:53:35 +0900 From: "Michael[tm] Smith" To: Ned Freed Message-ID: <20120808125333.GH68705@sideshowbarker> References: <20120807111647.GB67292@sideshowbarker> <01OISEPVDL760006TF@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01OISEPVDL760006TF@mauve.mrochek.com> User-Agent: Mutt/0488deb39a35+poontang (2012-05-24 22:02:57+09:00) Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Update to text/html registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 12:53:44 -0000 Ned Freed , 2012-08-07 23:06 -0700: > I should also point out that ietf-types is a review list only, and note that > posting stuff here does NOT make it a formal update request. Under the newly > adopted rules, that has to be done by submitting the update request to IANA. > > You may already be aware of this, but I given the wording of the messages I > thought it was a good idea to point it out. Actually I wasn't aware of it :-) But that explains a few things. So to be clear: Is the correct procedure now to use the http://www.iana.org/cgi-bin/mediatypes.pl form? --Mike -- Michael[tm] Smith http://people.w3.org/mike Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F86521F8568 for ; Wed, 8 Aug 2012 02:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4SeUgzQyPYW for ; Wed, 8 Aug 2012 02:00:37 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9157D21F85A0 for ; Wed, 8 Aug 2012 02:00:36 -0700 (PDT) Received: (qmail invoked by alias); 08 Aug 2012 09:00:33 -0000 Received: from host217-104-dynamic.51-79-r.retail.telecomitalia.it (EHLO Vostro3500) [79.51.104.217] by mail.gmx.net (mp016) with SMTP; 08 Aug 2012 11:00:33 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1/zQkZXBFPzvsN6/0SBEBS2c/L6l7WYraJqbbrhAL Fhgj7NwKRCKXo8 From: "Markus Lanthaler" To: "'Michael[tm] Smith'" , References: <20120807115025.GK67292@sideshowbarker> In-Reply-To: <20120807115025.GK67292@sideshowbarker> Date: Wed, 8 Aug 2012 11:00:24 +0200 Message-ID: <00c901cd7544$44c8d210$ce5a7630$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac10ktrjELC971ZLQhi9JZuHmUacGQAryijA Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [ietf-types] Registration for application/microdata+json X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 09:00:38 -0000 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. For example the following application/microdata+json document: { "items": [ { "id": "http://example.com/id1", "type": [ "http://example.com/type1" ], "properties": { "property1": [ "value1" ], "property2": [ { "id": "http://example.com/id2", "type": [ "http://example.com/type2", "http://example.com/type3" ], "properties": { "property3": [ "http://example.com/value3" ] } } ] } } ] } Could be expressed in JSON-LD as { "@graph": [ { "@id": "http://example.com/id1", "@type": [ "http://example.com/type1" ], "property1": [ "value1" ], "property2": [ { "@id": "http://example.com/id2", "@type": [ "http://example.com/type2", "http://example.com/type3" ], "properties": { "property3": [ { "@id": "http://example.com/value3" } ] } } ] } ] } Or, by aliasing JSON-LD's keywords even as which is almost exactly the same as the application/microdata+json counterpart: { "@context": { "id": "@id", "type": "@type", "items": "@graph" }, "items": [ { "id": "http://example.com/id1", "type": [ "http://example.com/type1" ], "property1": [ "value1" ], "property2": [ { "id": "http://example.com/id2", "type": [ "http://example.com/type2", "http://example.com/type3" ], "properties": { "property3": [ { "@id": "http://example.com/value3" } ] } } ] } ] } [1] http://www.w3.org/TR/json-ld-syntax/ -- Markus Lanthaler @markuslanthaler > -----Original Message----- > From: ietf-types-bounces@ietf.org [mailto:ietf-types-bounces@ietf.org] > On Behalf Of Michael[tm] Smith > Sent: Tuesday, August 07, 2012 1:50 PM > To: ietf-types@ietf.org > Subject: [ietf-types] 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 > > Intended usage: > Common > > Restrictions on usage: > No restrictions apply. > > Author: > Ian Hickson > > 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 > _______________________________________________ > ietf-types mailing list > ietf-types@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-types Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4473611E813F for ; Tue, 7 Aug 2012 23:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wG9lE5CQRbmO for ; Tue, 7 Aug 2012 23:19:59 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1DE11E8138 for ; Tue, 7 Aug 2012 23:19:59 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OISEPWW4XS0066VA@mauve.mrochek.com> for ietf-types@ietf.org; Tue, 7 Aug 2012 23:14:55 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Tue, 7 Aug 2012 23:14:52 -0700 (PDT) Message-id: <01OISEPVDL760006TF@mauve.mrochek.com> Date: Tue, 07 Aug 2012 23:06:25 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 07 Aug 2012 20:16:49 +0900" <20120807111647.GB67292@sideshowbarker> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120807111647.GB67292@sideshowbarker> To: "Michael[tm] Smith" Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Update to text/html registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 06:20:00 -0000 I should also point out that ietf-types is a review list only, and note that posting stuff here does NOT make it a formal update request. Under the newly adopted rules, that has to be done by submitting the update request to IANA. You may already be aware of this, but I given the wording of the messages I thought it was a good idea to point it out. Ned > Please update the registration for the text/html media type to reference > the HTML5 specification instead of RFC 2854. > http://www.w3.org/TR/html5/iana.html#text-html > --------------------------------------------------------------------------- > Type name: > text > Subtype name: > html > Required parameters: > No required parameters > Optional parameters: > charset > The charset parameter may be provided to definitively specify the > document's character encoding, overriding any character encoding > declarations in the document. The parameter's value must be the name of > the character encoding used to serialize the file, must be a valid > character encoding name, and must be an ASCII case-insensitive match > for the preferred MIME name for that encoding. [IANACHARSET] > Encoding considerations: > 8bit (see the section on character encoding declarations) > Security considerations: > Entire novels have been written about the security considerations that > apply to HTML documents. Many are listed in this document, to which the > reader is referred for more details. Some general concerns bear > mentioning here, however: > HTML is scripted language, and has a large number of APIs (some of which > are described in this document). Script can expose the user to potential > risks of information leakage, credential leakage, cross-site scripting > attacks, cross-site request forgeries, and a host of other problems. > While the designs in this specification are intended to be safe if > implemented correctly, a full implementation is a massive undertaking > and, as with any software, user agents are likely to have security bugs. > Even without scripting, there are specific features in HTML which, for > historical reasons, are required for broad compatibility with legacy > content but that expose the user to unfortunate security problems. In > particular, the img element can be used in conjunction with some other > features as a way to effect a port scan from the user's location on the > Internet. This can expose local network topologies that the attacker > would otherwise not be able to determine. > HTML relies on a compartmentalization scheme sometimes known as the > same-origin policy. An origin in most cases consists of all the pages > served from the same host, on the same port, using the same protocol. > It is critical, therefore, to ensure that any untrusted content that > forms part of a site be hosted on a different origin than any sensitive > content on that site. Untrusted content can easily spoof any other page > on the same origin, read data from that origin, cause scripts in that > origin to execute, submit forms to and from that origin even if they are > protected from cross-site request forgery attacks by unique tokens, and > make use of any third-party resources exposed to or rights granted to > that origin. > Interoperability considerations: > Rules for processing both conforming and non-conforming content are > defined in the HTML5 specification. > Published specification: > This HTML5 specification is the relevant specification. Labeling a > resource with the text/html type asserts that the resource is an HTML > document using the HTML syntax. > Applications that use this media type: > Web browsers, tools for processing Web content, HTML authoring tools, > search engines, validators. > Additional information: > Magic number(s): > No sequence of bytes can uniquely identify an HTML document. More > information on detecting HTML documents is available in the Media Type > Sniffing specification. > File extension(s): > "html" and "htm" are commonly, but certainly not exclusively, used as > the extension for HTML documents. > Macintosh file type code(s): > TEXT > Person & email address to contact for further information: > Michael[tm] Smith > Intended usage: > Common > Restrictions on usage: > No restrictions apply. > Author: > Ian Hickson > Change controller: > W3C > Fragment identifiers used with text/html resources either refer to the > indicated part of the document or provide state information for in-page > scripts. > --------------------------------------------------------------------------- > -- > Michael[tm] Smith http://people.w3.org/mike > _______________________________________________ > ietf-types mailing list > ietf-types@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-types Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A5F11E810D for ; Tue, 7 Aug 2012 18:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.199 X-Spam-Level: X-Spam-Status: No, score=-104.199 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zukH-gz0OOKZ for ; Tue, 7 Aug 2012 18:17:57 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 580EC11E810B for ; Tue, 7 Aug 2012 18:17:57 -0700 (PDT) Received: from [10.10.1.125] (unknown [67.79.29.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 583F150A5D; Tue, 7 Aug 2012 21:17:49 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Mark Nottingham In-Reply-To: <20120807113601.GH67292@sideshowbarker> Date: Tue, 7 Aug 2012 20:17:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0AB1A4C6-9E6A-4CDB-AD86-383D58B7EE0B@mnot.net> References: <20120807113601.GH67292@sideshowbarker> To: Michael[tm] Smith X-Mailer: Apple Mail (2.1485) Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Registration for application/x-www-form-urlencoded X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 01:17:58 -0000 Hi Michael, On 07/08/2012, at 6:36 AM, Michael[tm] Smith wrote: > This is a request to register the application/x-www-form-urlencoded = media > type by reference to the HTML5 specification: >=20 > = http://www.w3.org/TR/html5/iana.html#application-x-www-form-urlencoded >=20 [=85] > Interoperability considerations: > Rules for generating and processing application/x-www-form-urlencoded > payloads are defined in the HTML5 specification. HTML4 encouraged = the use of a semi-colon as a delimiter in some uses of this type. = AFAICT, HTML5 doesn't say anything about it. A number of libraries (e.g., Python's urlparse.parse_qs) do treat a = semicolon as a delimiter, based upon this advice. IME this has led to = interop problems, as some software thinks it's data, while other = software thinks it's a delimiter. It would be good if this could be clarified; e.g., a note to the effect = that semicolon is NOT a delimiter, even though it was encouraged in the = past (that makes filing appropriate bugs easier). That could be done here, or somewhere else in the HTML5 spec. Cheers, -- Mark Nottingham http://www.mnot.net/ Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55ED921F8659 for ; Tue, 7 Aug 2012 15:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKdttLnY4Pw4 for ; Tue, 7 Aug 2012 15:33:50 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C7A7021F8646 for ; Tue, 7 Aug 2012 15:33:50 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIRYG0CUQO006PF5@mauve.mrochek.com> for ietf-types@ietf.org; Tue, 7 Aug 2012 15:28:48 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Tue, 7 Aug 2012 15:28:46 -0700 (PDT) Message-id: <01OIRYFYVNZK0006TF@mauve.mrochek.com> Date: Tue, 07 Aug 2012 15:25:03 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 08 Aug 2012 02:14:21 +0900" <20120807171420.GG68105@sideshowbarker> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120807111647.GB67292@sideshowbarker> <20120807171420.GG68105@sideshowbarker> To: "Michael[tm] Smith" Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Update to text/html registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 22:33:51 -0000 > Paul Libbrecht , 2012-08-07 15:14 +0200: > > Michael, > > > > HTML is very commonly exchanged over clipboards in widespread operating systems. > > Could I suggest that you enrich the registrations of html and xhtml so that you include two fields with > > - Windows Clipboard Flavor Name > > - Macintosh Uniform Type Identifier > Are those important just for HTML and XHTML, or are there other formats > which would benefit from having those defined as part of their > registrations? They probably are. > If those would be useful or other formats, I'd suggest the guidelines for > media-type registrations be updated to suggest including them for all > registrations. I'm afraid it is a little late for that. The media types registration were just updated. Had this been proposed during the updating process (which took over a years), I can pretty much guarantee it would have been included, but the document is now final and it's too late. By way of reference, the last update happened in 2005. My suggestion would be to put these in the additional information section. Ned Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABC721F86C2 for ; Tue, 7 Aug 2012 10:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.458 X-Spam-Level: X-Spam-Status: No, score=-10.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYs9EZU+4HgT for ; Tue, 7 Aug 2012 10:28:44 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 9B75A21F867D for ; Tue, 7 Aug 2012 10:28:44 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=MikeSmith.local) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1SynaF-00070a-EM; Tue, 07 Aug 2012 13:28:44 -0400 Date: Wed, 8 Aug 2012 02:28:41 +0900 From: "Michael[tm] Smith" To: Mark Baker Message-ID: <20120807172840.GH68105@sideshowbarker> References: <20120807111647.GB67292@sideshowbarker> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/0488deb39a35+poontang (2012-05-24 22:02:57+09:00) Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Update to text/html registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 17:28:45 -0000 Mark Baker , 2012-08-07 10:00 -0400: > Hi Mike, > > I left the WG when HTML5 was deliberately backwards-incompatible, Not sure what in particular you thought was deliberately backwards- incompatible, but OK. > making the update of text/html an error. AFAICT, this appears to have > since been addressed, at least judging by the text here; > > http://www.w3.org/TR/html5-diff/#backwards-compatible I think that's just stating something that's always been true. The HTML5 spec has always intended to be backwards-compatible for existing browser behavior. That has been the number one design principle of this entire effort from day one: http://www.w3.org/TR/html-design-principles/#support-existing-content > I recommend that the interoperability considerations section mention > this. Something as simple as; > > "HTML5 is backwards compatible with all previous versions of HTML as > implemented. See > http://www.w3.org/TR/html5-diff/#backwards-compatible" It's not intended to be "backwards compatible with all previous versions of HTML". Judging whether anything is compatible with HTML4 has always been a guessing-game exercise in creative interpretation. The HTML4 spec does not actually state user-agent requirements in such as way that it's possible to evaluate or test conformance to the HTML4 spec. > I included "as implemented" because I know the editors were always > keen to point out where multiple independent implementations strayed > from the specifications (and rightly so). Outside of those differences, the HTML5 spec has always intended to be compatible with existing behavior in browsers, which is generally not open to being changed. So I'm not sure I'd actually call that "backwards" compatibility. It's more like just compatibility with the Web. Anyway, as a I pointed out to Paul, the details for this registration are defined in the HTML5 spec itself. So if you want your proposed wording added, I suggest you raise a bug against the HTML5 spec: http://w3.org/brief/MjA2 -- Michael[tm] Smith http://people.w3.org/mike Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CED121F85D0 for ; Tue, 7 Aug 2012 10:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.442 X-Spam-Level: X-Spam-Status: No, score=-10.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TVnz+4-vDzN for ; Tue, 7 Aug 2012 10:14:24 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id A224F21F859A for ; Tue, 7 Aug 2012 10:14:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=MikeSmith.local) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1SynMN-00066u-Ak; Tue, 07 Aug 2012 13:14:24 -0400 Date: Wed, 8 Aug 2012 02:14:21 +0900 From: "Michael[tm] Smith" To: Paul Libbrecht Message-ID: <20120807171420.GG68105@sideshowbarker> References: <20120807111647.GB67292@sideshowbarker> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/0488deb39a35+poontang (2012-05-24 22:02:57+09:00) Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Update to text/html registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 17:14:25 -0000 Paul Libbrecht , 2012-08-07 15:14 +0200: > Michael, > > HTML is very commonly exchanged over clipboards in widespread operating systems. > Could I suggest that you enrich the registrations of html and xhtml so that you include two fields with > - Windows Clipboard Flavor Name > - Macintosh Uniform Type Identifier Are those important just for HTML and XHTML, or are there other formats which would benefit from having those defined as part of their registrations? If those would be useful or other formats, I'd suggest the guidelines for media-type registrations be updated to suggest including them for all registrations. > This way platforms, which mostly already define these types, would do so > based on an open standard. > > I can try to research the possible values if you want. I am not sure > about the multipart media type but I suspect this would also be welcome > (maybe for html with attached objects?). The details for this registration are defined in the HTML5 spec, so I suggest that if you want to make sure that data for those suggested fields is included, it would be best to file a bug against the HTML5 spec itself: http://w3.org/brief/MjA2 -- Michael[tm] Smith http://people.w3.org/mike Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76E721F867C for ; Tue, 7 Aug 2012 07:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+R706Z6DuBw for ; Tue, 7 Aug 2012 07:00:27 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D50B621F85C0 for ; Tue, 7 Aug 2012 07:00:26 -0700 (PDT) Received: by weyu54 with SMTP id u54so3141906wey.31 for ; Tue, 07 Aug 2012 07:00:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=U2kYpL6EH1NiD9PSfPuT1XPRpuuUpTyCgSWKPLSDSlQ=; b=oJ9Chq1Cbb4j8ePLW8RJpKGoOzvWWug63V25g6nf8tcOE7etxYZ5sd0P7m2JtooYcm Zz+6IrpK0ccm06Ys9h8GfQ5EunMIXGVK3E025j/Wr02Wy5NmrkQFnK2umRUX3fP4ZjHH 2SOVDswjbj6uFlLszS8TLON1e4P0TY9dV0aF1cr8cczvHerHr6YDge0R3vSr8tAumHdo cIbgP1xxs2+fyfP0ytMiULFCl6Izivqyk5sYCBcYuaVZG791fSqePiNaG95OFTWuyRPU gd8qtJK5gt6PrRzKjp7ji8Dj4Ao2g0mVHXPaeeHfJhPKF0QOI0TTN/6UmSNFOAw37Mng AlKg== MIME-Version: 1.0 Received: by 10.180.92.9 with SMTP id ci9mr27777717wib.22.1344348025525; Tue, 07 Aug 2012 07:00:25 -0700 (PDT) Sender: mark@coactus.com Received: by 10.217.5.132 with HTTP; Tue, 7 Aug 2012 07:00:25 -0700 (PDT) In-Reply-To: <20120807111647.GB67292@sideshowbarker> References: <20120807111647.GB67292@sideshowbarker> Date: Tue, 7 Aug 2012 10:00:25 -0400 X-Google-Sender-Auth: dNGR8M1SFrGiE44a2ruEd-uQ2Zw Message-ID: From: Mark Baker To: "Michael[tm] Smith" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlrAoEan/1T88iLiJ5zDCExlX2MNiJfgYrGlODH2n09KS2m4Thi28Vgfup5kNJVGVCSW4H2 Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Update to text/html registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 14:00:28 -0000 Hi Mike, I left the WG when HTML5 was deliberately backwards-incompatible, making the update of text/html an error. AFAICT, this appears to have since been addressed, at least judging by the text here; http://www.w3.org/TR/html5-diff/#backwards-compatible I recommend that the interoperability considerations section mention this. Something as simple as; "HTML5 is backwards compatible with all previous versions of HTML as implemented. See http://www.w3.org/TR/html5-diff/#backwards-compatible" I included "as implemented" because I know the editors were always keen to point out where multiple independent implementations strayed from the specifications (and rightly so). Mark. Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1804621F86D1 for ; Tue, 7 Aug 2012 06:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySN13OjlBhD7 for ; Tue, 7 Aug 2012 06:14:40 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5773821F86B4 for ; Tue, 7 Aug 2012 06:14:40 -0700 (PDT) Received: from [192.168.178.43] (p5DDEC306.dip0.t-ipconnect.de [93.222.195.6]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0Mgrky-1TKmjs3e7M-00MZeh; Tue, 07 Aug 2012 15:14:37 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Paul Libbrecht In-Reply-To: <20120807111647.GB67292@sideshowbarker> Date: Tue, 7 Aug 2012 15:14:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120807111647.GB67292@sideshowbarker> To: Michael[tm] Smith X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:egVbsmX/LsrWCNUVjlSu88KP0PU7Ut4RO5kcYilUYU9 bnSTsUic1EB+6XcfK2Lj8ZgpmA8UcB62VRD0ws7RUhWfW7LIXa Lgh+NVzd5wX2Zms0U1CyO8kuxCcRnbySLs1WjtItptAkN0QTzw 1n5ADpJHFYl0fdu/uayeYiSxScMt8/kMlubgse7lcAcP5YZOio AxuN0GUFvGOH3853nq5m9osUny2BLIgJi7s1M2psoZ/Ey1EnjY CLF/e6smse9EiZQbMC8PSPHIJ9VHYTTHTamwAHT+y5jSKJmf34 D51czkduRh6PpBJFmtH/mqWGIHDh8D6bNPvELFWL2y0pki+PoE 5qsb0zIWDLXgWVZd56DBWby/hE1gzSQndOrkukhD7IntNb25Rd OWSvVo4g8MHxQ== Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Update to text/html registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 13:14:42 -0000 Michael, HTML is very commonly exchanged over clipboards in widespread operating = systems. Could I suggest that you enrich the registrations of html and xhtml so = that you include two fields with - Windows Clipboard Flavor Name - Macintosh Uniform Type Identifier This way platforms, which mostly already define these types, would do so = based on an open standard. I can try to research the possible values if you want. I am not sure about the multipart media type but I suspect this would = also be welcome (maybe for html with attached objects?). Paul PS: I feel the Macintosh file type code is obsolete and unused. Le 7 ao=FBt 2012 =E0 13:16, Michael[tm] Smith a =E9crit : > Please update the registration for the text/html media type to = reference > the HTML5 specification instead of RFC 2854. >=20 > http://www.w3.org/TR/html5/iana.html#text-html >=20 > = --------------------------------------------------------------------------= - > Type name: > text >=20 > Subtype name: > html >=20 > Required parameters: > No required parameters >=20 > Optional parameters: > charset > The charset parameter may be provided to definitively specify the > document's character encoding, overriding any character encoding > declarations in the document. The parameter's value must be the = name of > the character encoding used to serialize the file, must be a valid > character encoding name, and must be an ASCII case-insensitive = match > for the preferred MIME name for that encoding. [IANACHARSET] >=20 > Encoding considerations: > 8bit (see the section on character encoding declarations) >=20 > Security considerations: > Entire novels have been written about the security considerations = that > apply to HTML documents. Many are listed in this document, to which = the > reader is referred for more details. Some general concerns bear > mentioning here, however: >=20 > HTML is scripted language, and has a large number of APIs (some of = which > are described in this document). Script can expose the user to = potential > risks of information leakage, credential leakage, cross-site = scripting > attacks, cross-site request forgeries, and a host of other problems. > While the designs in this specification are intended to be safe if > implemented correctly, a full implementation is a massive undertaking > and, as with any software, user agents are likely to have security = bugs. >=20 > Even without scripting, there are specific features in HTML which, = for > historical reasons, are required for broad compatibility with legacy > content but that expose the user to unfortunate security problems. In > particular, the img element can be used in conjunction with some = other > features as a way to effect a port scan from the user's location on = the > Internet. This can expose local network topologies that the attacker > would otherwise not be able to determine. >=20 > HTML relies on a compartmentalization scheme sometimes known as the > same-origin policy. An origin in most cases consists of all the pages > served from the same host, on the same port, using the same protocol. >=20 > It is critical, therefore, to ensure that any untrusted content that > forms part of a site be hosted on a different origin than any = sensitive > content on that site. Untrusted content can easily spoof any other = page > on the same origin, read data from that origin, cause scripts in that > origin to execute, submit forms to and from that origin even if they = are > protected from cross-site request forgery attacks by unique tokens, = and > make use of any third-party resources exposed to or rights granted to > that origin. >=20 > Interoperability considerations: > Rules for processing both conforming and non-conforming content are > defined in the HTML5 specification. >=20 > Published specification: > This HTML5 specification is the relevant specification. Labeling a > resource with the text/html type asserts that the resource is an HTML > document using the HTML syntax. >=20 > Applications that use this media type: > Web browsers, tools for processing Web content, HTML authoring tools, > search engines, validators. >=20 > Additional information: > Magic number(s): > No sequence of bytes can uniquely identify an HTML document. More > information on detecting HTML documents is available in the Media = Type > Sniffing specification. >=20 > File extension(s): > "html" and "htm" are commonly, but certainly not exclusively, = used as > the extension for HTML documents. >=20 > Macintosh file type code(s): > TEXT >=20 > Person & email address to contact for further information: > Michael[tm] Smith >=20 > Intended usage: > Common >=20 > Restrictions on usage: > No restrictions apply. >=20 > Author: > Ian Hickson >=20 > Change controller: > W3C >=20 > Fragment identifiers used with text/html resources either refer to the > indicated part of the document or provide state information for = in-page > scripts. > = --------------------------------------------------------------------------= - >=20 > --=20 > Michael[tm] Smith http://people.w3.org/mike > _______________________________________________ > ietf-types mailing list > ietf-types@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-types Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E829A21F855A for ; Tue, 7 Aug 2012 04:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.423 X-Spam-Level: X-Spam-Status: No, score=-10.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyRkCL5R8a8x for ; Tue, 7 Aug 2012 04:50:31 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0033521F8559 for ; Tue, 7 Aug 2012 04:50:30 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=MikeSmith.local) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1SyiIv-0002QU-9f; Tue, 07 Aug 2012 07:50:30 -0400 Date: Tue, 7 Aug 2012 20:50:27 +0900 From: "Michael[tm] Smith" To: ietf-types@ietf.org Message-ID: <20120807115025.GK67292@sideshowbarker> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/0488deb39a35+poontang (2012-05-24 22:02:57+09:00) Subject: [ietf-types] Registration for application/microdata+json X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 11:50:32 -0000 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 Intended usage: Common Restrictions on usage: No restrictions apply. Author: Ian Hickson 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 Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9AF821F86DE for ; Tue, 7 Aug 2012 04:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.398 X-Spam-Level: X-Spam-Status: No, score=-10.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-EUqrsmg4ju for ; Tue, 7 Aug 2012 04:45:56 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 01EA421F86D8 for ; Tue, 7 Aug 2012 04:45:55 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=MikeSmith.local) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1SyiEV-0002Cy-2H; Tue, 07 Aug 2012 07:45:55 -0400 Date: Tue, 7 Aug 2012 20:45:52 +0900 From: "Michael[tm] Smith" To: ietf-types@ietf.org Message-ID: <20120807114550.GJ67292@sideshowbarker> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/0488deb39a35+poontang (2012-05-24 22:02:57+09:00) Subject: [ietf-types] Registration for text/event-stream X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 11:45:56 -0000 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 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 Change controller: W3C Fragment identifiers have no meaning with text/event-stream resources. --------------------------------------------------------------------------- -- Michael[tm] Smith http://people.w3.org/mike Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A6521F86F6 for ; Tue, 7 Aug 2012 04:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.364 X-Spam-Level: X-Spam-Status: No, score=-10.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SUx15Z-BksB for ; Tue, 7 Aug 2012 04:40:17 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id F17B321F86A2 for ; Tue, 7 Aug 2012 04:40:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=MikeSmith.local) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Syi90-0001tk-8o; Tue, 07 Aug 2012 07:40:15 -0400 Date: Tue, 7 Aug 2012 20:40:12 +0900 From: "Michael[tm] Smith" To: ietf-types@ietf.org Message-ID: <20120807114011.GI67292@sideshowbarker> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/0488deb39a35+poontang (2012-05-24 22:02:57+09:00) Subject: [ietf-types] Registration for text/cache-manifest X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 11:40:19 -0000 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 Intended usage: Common Restrictions on usage: No restrictions apply. Author: Ian Hickson Change controller: W3C Fragment identifiers have no meaning with text/cache-manifest resources. --------------------------------------------------------------------------- -- Michael[tm] Smith http://people.w3.org/mike Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C940421F86EC for ; Tue, 7 Aug 2012 04:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.247 X-Spam-Level: X-Spam-Status: No, score=-10.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuRLi5cE9L-N for ; Tue, 7 Aug 2012 04:36:08 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 6FECC21F86EA for ; Tue, 7 Aug 2012 04:36:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=MikeSmith.local) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Syi4y-0001iW-Qn; Tue, 07 Aug 2012 07:36:06 -0400 Date: Tue, 7 Aug 2012 20:36:02 +0900 From: "Michael[tm] Smith" To: ietf-types@ietf.org Message-ID: <20120807113601.GH67292@sideshowbarker> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/0488deb39a35+poontang (2012-05-24 22:02:57+09:00) Subject: [ietf-types] Registration for application/x-www-form-urlencoded X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 11:36:09 -0000 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 Intended usage: Common Restrictions on usage: This type is only intended to be used to describe HTML form submission payloads. Author: Ian Hickson 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 Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9142921F843F for ; Tue, 7 Aug 2012 04:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.129 X-Spam-Level: X-Spam-Status: No, score=-10.129 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOIN9XOiZ1P4 for ; Tue, 7 Aug 2012 04:35:25 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 4360121F8508 for ; Tue, 7 Aug 2012 04:35:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=MikeSmith.local) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Syi4J-0001gG-Ul; Tue, 07 Aug 2012 07:35:24 -0400 Date: Tue, 7 Aug 2012 20:35:21 +0900 From: "Michael[tm] Smith" To: ietf-types@ietf.org Message-ID: <20120807113520.GG67292@sideshowbarker> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/0488deb39a35+poontang (2012-05-24 22:02:57+09:00) Subject: [ietf-types] Registration for multipart/x-mixed-replace X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 11:35:25 -0000 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 Intended usage: Common Restrictions on usage: No restrictions apply. Author: Ian Hickson 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 Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E4E21F86C5 for ; Tue, 7 Aug 2012 04:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.744 X-Spam-Level: X-Spam-Status: No, score=-9.744 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUJ7sCCV6WuA for ; Tue, 7 Aug 2012 04:21:44 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 570DF21F86B5 for ; Tue, 7 Aug 2012 04:21:44 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=MikeSmith.local) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Syhr5-00011B-CG; Tue, 07 Aug 2012 07:21:44 -0400 Date: Tue, 7 Aug 2012 20:21:41 +0900 From: "Michael[tm] Smith" To: ietf-types@ietf.org Message-ID: <20120807112140.GC67292@sideshowbarker> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/0488deb39a35+poontang (2012-05-24 22:02:57+09:00) Subject: [ietf-types] Update to application/xhtml+xml media type X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 11:21:45 -0000 Please update the registration for the application/xhtml+xml media type to reference the HTML5 spec instead of RFC 3236. http://www.w3.org/TR/html5/iana.html#application-xhtml-xml --------------------------------------------------------------------------- Type name: application Subtype name: xhtml+xml Required parameters: Same as for application/xml [RFC3023] Optional parameters: Same as for application/xml [RFC3023] Encoding considerations: Same as for application/xml [RFC3023] Security considerations: Same as for application/xml [RFC3023] Interoperability considerations: Same as for application/xml [RFC3023] Published specification: Labeling a resource with the application/xhtml+xml type asserts that the resource is an XML document that likely has a root element from the HTML namespace. Thus, the relevant specifications are the XML specification, the Namespaces in XML specification, and the HTML5 specification. Applications that use this media type: Same as for application/xml [RFC3023] Additional information: Magic number(s): Same as for application/xml [RFC3023] File extension(s): "xhtml" and "xht" are sometimes used as extensions for XML resources that have a root element from the HTML namespace. Macintosh file type code(s): TEXT Person & email address to contact for further information: Michael[tm] Smith Intended usage: Common Restrictions on usage: No restrictions apply. Author: Ian Hickson Change controller: W3C Fragment identifiers used with application/xhtml+xml resources have the same semantics as with any XML MIME type. [RFC3023] --------------------------------------------------------------------------- -- Michael[tm] Smith http://people.w3.org/mike Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C4421F8674 for ; Tue, 7 Aug 2012 04:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.489 X-Spam-Level: X-Spam-Status: No, score=-9.489 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mw2vjLrO3El for ; Tue, 7 Aug 2012 04:16:52 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id DD31D21F8671 for ; Tue, 7 Aug 2012 04:16:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=MikeSmith.local) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1SyhmN-0000eB-9o; Tue, 07 Aug 2012 07:16:52 -0400 Date: Tue, 7 Aug 2012 20:16:49 +0900 From: "Michael[tm] Smith" To: ietf-types@ietf.org Message-ID: <20120807111647.GB67292@sideshowbarker> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/0488deb39a35+poontang (2012-05-24 22:02:57+09:00) Subject: [ietf-types] Update to text/html registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 11:16:53 -0000 Please update the registration for the text/html media type to reference the HTML5 specification instead of RFC 2854. http://www.w3.org/TR/html5/iana.html#text-html --------------------------------------------------------------------------- Type name: text Subtype name: html Required parameters: No required parameters Optional parameters: charset The charset parameter may be provided to definitively specify the document's character encoding, overriding any character encoding declarations in the document. The parameter's value must be the name of the character encoding used to serialize the file, must be a valid character encoding name, and must be an ASCII case-insensitive match for the preferred MIME name for that encoding. [IANACHARSET] Encoding considerations: 8bit (see the section on character encoding declarations) Security considerations: Entire novels have been written about the security considerations that apply to HTML documents. Many are listed in this document, to which the reader is referred for more details. Some general concerns bear mentioning here, however: HTML is scripted language, and has a large number of APIs (some of which are described in this document). Script can expose the user to potential risks of information leakage, credential leakage, cross-site scripting attacks, cross-site request forgeries, and a host of other problems. While the designs in this specification are intended to be safe if implemented correctly, a full implementation is a massive undertaking and, as with any software, user agents are likely to have security bugs. Even without scripting, there are specific features in HTML which, for historical reasons, are required for broad compatibility with legacy content but that expose the user to unfortunate security problems. In particular, the img element can be used in conjunction with some other features as a way to effect a port scan from the user's location on the Internet. This can expose local network topologies that the attacker would otherwise not be able to determine. HTML relies on a compartmentalization scheme sometimes known as the same-origin policy. An origin in most cases consists of all the pages served from the same host, on the same port, using the same protocol. It is critical, therefore, to ensure that any untrusted content that forms part of a site be hosted on a different origin than any sensitive content on that site. Untrusted content can easily spoof any other page on the same origin, read data from that origin, cause scripts in that origin to execute, submit forms to and from that origin even if they are protected from cross-site request forgery attacks by unique tokens, and make use of any third-party resources exposed to or rights granted to that origin. Interoperability considerations: Rules for processing both conforming and non-conforming content are defined in the HTML5 specification. Published specification: This HTML5 specification is the relevant specification. Labeling a resource with the text/html type asserts that the resource is an HTML document using the HTML syntax. Applications that use this media type: Web browsers, tools for processing Web content, HTML authoring tools, search engines, validators. Additional information: Magic number(s): No sequence of bytes can uniquely identify an HTML document. More information on detecting HTML documents is available in the Media Type Sniffing specification. File extension(s): "html" and "htm" are commonly, but certainly not exclusively, used as the extension for HTML documents. Macintosh file type code(s): TEXT Person & email address to contact for further information: Michael[tm] Smith Intended usage: Common Restrictions on usage: No restrictions apply. Author: Ian Hickson Change controller: W3C Fragment identifiers used with text/html resources either refer to the indicated part of the document or provide state information for in-page scripts. --------------------------------------------------------------------------- -- Michael[tm] Smith http://people.w3.org/mike