In = that sepecification, section C.14 has the MIME type registration informatio= n, and is extracted bellow for your consideration/review.

Ple= ase let me know if additional information or questions you may have.

Tha= nk you,

Eric Turcotte<= /span>

C.14 Registration of MIME type "application/mbms-schedule+xml&qu= ot;

The MIME-Type registration for "applicat= ion/mbms-schedule+xml" identifies XML documents that follows the s= chema " urn:3gpp:metadata:2011:MBMS= :scheduleDescription " defined in clause 1= 1.2A.2.

= Type name: application

= Subtype name: mbms-schedule+xml

= Required parameters:

None

= Optional parameters:

charset: As specified in = RFC 3023 [83] for media type application/xml.

= Encoding considerations:

This is an XML document and= the encoding considerations are the same as for media type "applicati= on/xml" defined in RFC 3023 [83].

= Security considerations:

The information present in = this media format is used to configure the receiving application. Thus the = usage of the fomat is vulnerable to attacks modifying or spoofing the content of this format. It is recommended to use= source authentication and integrity protection.

= Interoperability considerations:

None

= Published specification:

3GPP TS 26.346

= Applications which use this media type:

3GPP MBMS based applicati= ons

= Additional information:

= Magic number(s): None

= File extension(s):

= Macintosh file type code(s):

= Person & email address to contact for fu= rther information:

Eric Turcotte (Eric.Turcotte@ericsson.com= )
3GPP TSG SA WG4

Intended usage: COMMON

Restrictions on= usage:

None

Author:

3GPP TSG SA WG4

Change controll= er:

3GPP TSG SA WG4

--_000_918C98C9EE8A0C489EB362DC13E0D6030161D8EUSAAMB101ericsso_-- From ned.freed@mrochek.com Fri Nov 16 09:09:00 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A4121F8745 for ; Fri, 16 Nov 2012 09:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.482 X-Spam-Level: X-Spam-Status: No, score=-1.482 tagged_above=-999 required=5 tests=[AWL=-1.037, BAYES_00=-2.599, FRT_BELOW2=2.154] 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 7DXN53cHmBvj for ; Fri, 16 Nov 2012 09:09:00 -0800 (PST) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3D821F86E6 for ; Fri, 16 Nov 2012 09:09:00 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id qAGH8d1A004052 for ; Fri, 16 Nov 2012 17:08:59 GMT Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMOOFBT38W001WBB@mauve.mrochek.com> for media-types@iana.org; Fri, 16 Nov 2012 09:03:37 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMGB2WUMLC00008S@mauve.mrochek.com>; Fri, 16 Nov 2012 09:03:35 -0800 (PST) Message-id: <01OMOOFANQW400008S@mauve.mrochek.com> Date: Fri, 16 Nov 2012 09:00:43 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 16 Nov 2012 15:29:50 +0000" <918C98C9EE8A0C489EB362DC13E0D6030161D8@EUSAAMB101.ericsson.se> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <918C98C9EE8A0C489EB362DC13E0D6030161D8@EUSAAMB101.ericsson.se> To: Eric Turcotte X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Fri, 16 Nov 2012 17:09:00 +0000 (UTC) Cc: "media-types@iana.org" Subject: Re: [media-types] MIME Type registration X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 17:09:01 -0000 A couple of comments... > Hi, > I would like to register (in the standards tree) a new MIME type that has been defined in 3GPP working group SA4. The 3GPP specification where this is defined is: > http://www.3gpp.org/ftp/Specs/archive/26_series/26.346/26346-980.zip. > In that sepecification, section C.14 has the MIME type registration information, and is extracted bellow for your consideration/review. > Please let me know if additional information or questions you may have. > Thank you, > Eric Turcotte > C.14 Registration of MIME type "application/mbms-schedule+xml" > The MIME-Type registration for "application/mbms-schedule+xml" identifies XML documents that follows the schema " urn:3gpp:metadata:2011:MBMS:scheduleDescription " defined in clause 11.2A.2. > Type name: application > Subtype name: mbms-schedule+xml > Required parameters: > None > Optional parameters: > charset: As specified in RFC 3023 [83] for media type application/xml. > Encoding considerations: > This is an XML document and the encoding considerations are the same as for > media type "application/xml" defined in RFC 3023 [83]. It's fine to add this, but you still need to specify the encoding. If the type is limited to utf-8 and similar charsets 8bit is appropriate, if utf-16 variants are allowed it needs to be binary. > Security considerations: > The information present in this media format is used to configure the > receiving application. Thus the usage of the fomat is vulnerable to attacks > modifying or spoofing the content of this format. It is recommended to use > source authentication and integrity protection. You should also comment on any need, or the lack of any need, for privacy protection. That is, does this configuration information contain passwords or keys similar things? > Interoperability considerations: > None > Published specification: > 3GPP TS 26.346 > Applications which use this media type: > 3GPP MBMS based applications > Additional information: > Magic number(s): None > File extension(s): > Macintosh file type code(s): > Person & email address to contact for further information: > Eric Turcotte (Eric.Turcotte@ericsson.com) > 3GPP TSG SA WG4 > Intended usage: COMMON > Restrictions on usage: > None > Author: > 3GPP TSG SA WG4 > Change controller: > 3GPP TSG SA WG4 Ned From yakov@shaftek.org Fri Nov 16 11:46:05 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D71D21F8A7A for ; Fri, 16 Nov 2012 11:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-1] 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 CLMQJ1n6ouaG for ; Fri, 16 Nov 2012 11:46:04 -0800 (PST) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) by ietfa.amsl.com (Postfix) with ESMTP id 6D91421F847F for ; Fri, 16 Nov 2012 11:46:03 -0800 (PST) Received: from mail-vb0-f41.google.com (mail-vb0-f41.google.com [209.85.212.41]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id qAGJjg0s012152 for ; Fri, 16 Nov 2012 19:46:03 GMT Received: by mail-vb0-f41.google.com with SMTP id v13so2991327vbk.28 for ; Fri, 16 Nov 2012 11:45:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=/hb5ePIOZIRPWEJUui+55+MWM7OPOPJlQuXuHi6cJtQ=; b=OYsD2qCrNvMDT4j6rHwuCJvl+2/hdZe7JA4Yn439ajeoRw9DbE/gqEa65IYf/n5qWE VSnKsFnp4I02b+ozo1qWO2hPaWhZdrFlWponR9Yue+ptsof8thLDZMevhnLxFP5d2nRr zl0uduCpkJ/+xrgSCTV7jW3uArnCzIgQZJQd4rp5ImhfVyWF00cSMVeYBJigdiNp32u1 lx+MXcyc9Z9Dk8CDEuMVuYPjQZjCIGPOm+BrLnl7wyB+qFV4yhiiebb1gp7y60rIhLQM 46tHuOfuSMYYTbzNHdO76lmgL9Z33jjbkMDTRrj09GGF5m0Ah/inklwDPi5QlHs9v9zp FlOw== Received: by 10.52.100.65 with SMTP id ew1mr7159798vdb.125.1353095142352; Fri, 16 Nov 2012 11:45:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.209.134 with HTTP; Fri, 16 Nov 2012 11:45:10 -0800 (PST) X-Originating-IP: [173.13.252.213] In-Reply-To: <20121116145116.GB3174@w3.org> References:

<50A5CE66.4020608@it.aoyama.ac.jp> <20121116145116.GB3174@w3.org> From: Yakov Shafranovich Date: Fri, 16 Nov 2012 14:45:10 -0500 Message-ID: To: "Eric Prud'hommeaux" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk2JKETPtNV0RunCKJQqXIFl5p96tKJ70O1uvbPbA1gexHTm6qpVq5KNAJGYkiz5DRozDBL X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Fri, 16 Nov 2012 19:46:03 +0000 (UTC) Cc: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= , media-types@iana.org Subject: Re: [media-types] New media registration request: application/sql X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 19:46:05 -0000 On Fri, Nov 16, 2012 at 9:51 AM, Eric Prud'hommeaux wrote: > * Yakov Shafranovich [2012-11-16 08:04-0500] >> On Fri, Nov 16, 2012 at 12:25 AM, "Martin J. D=FCrst" >> wrote: >> > Hello Yakov, >> > >> > >> > On 2012/11/16 12:46, Yakov Shafranovich wrote: >> >> Encoding considerations: >> >> >> >> While SQL uses US-ASCII by default, some implementations may u= se >> >> other encodings including [Unicode]. >> > >> > >> > How are these encodings indicated? If there's no way to indicate them, >> > that's a bad idea (interoperability failure), and should be avoided. >> > >> > Regards, Martin. >> >> Thanks for the comment! >> >> Would adding "charset" as an optional parameter to indicate encoding >> help to resolve this? > > I believe this would be one path to ameliorating the pain of issuing > DDL and SQL requests. Creating UTF-8 tables and insert non-ascii data > is done entirely differently with e.g. Postgres, Oracle and MySQL. I > would applaud any efforts to improve this. > > The downside of permitting a charset parameter with an arbitrary > charset parameter is that server interfaces must then accept an > arbitrary set of character encodings, passing them on to the server in > the same encoding, if the server supports that encoding=B9, or > transcoding to a supported encoding. To give a scale of this > implementation burden, > > describes more than 50 as "common" character encodings. > > =B9 This is complicated by the fact that tables created with one > encoding may not support INSERTs, DELETEs, SELECTs in another > encoding. > > The XML approach to solving this was to mandate that UTF-8 and UTF-16 > MUST be supported (see ). This > complicates parsers by demanding relatively complex encoding detection > heuristics and byte-order markers. > > A simpler approach was used by e.g. text/turtle, which mandated one > encoding: > [[ > Optional parameters: > charset =97 this parameter is required when transferring non-ASCII > data. If present, the value of charset is always UTF-8. > ]] =97 > > This simplifies parsing and reduces (or frequently liminates) the > transcoding requirements. > > Considering these schemes in light of an SQL agent G issuing a query > to a service S, the choices are: > > do nothing: G can only count on S to handle requests entirely in > ASCII. Any non-ASCII treatment would be outside of the spec. > > arbitrary charset: G must find out by external means what encodings > are supported by S. At that point, non-ASCII messages are in-spec > and indicated by the charset parameter. > > guaranteed charsets: G can count on S accepting the guaranteed > encodings. Other encodings would have to be negotiated as above. > > fixed charset: G must submit requests the appropriate encoding. (If > G is accepting user input from e.g. KOI8R, the burden of transcoding > is on G.) > > If not already apparent, I support the fixed charset approach. Thanks for that information. I think I am going to do a survey of what the major database systems in order to see if it is feasible to settle on a fixed character set or a subset of encodings. > I also urge you to register text/sql instead of application/sql. > My impression has been that programming languages are usually registered under the "application" tree as opposed to the "text" tree. As per (http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-14#se= ction-4.2.5): "The "application" top-level type is to be used for discrete data that do not fit under any of the other type names, and particularly for data to be processed by some type of application program." and "Expected uses for the "application" type name include but are not limited to file transfer, spreadsheets, presentations, scheduling data, and languages for "active"(computational) material." A quick perusal of the "text" tree shows that other than CSS and HTML, most languages are registered under "application". The closest example to SQL is perhaps SPARQL which is also registered under "application". Yakov From ericw3c@gmail.com Fri Nov 16 13:12:14 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E52021F8A74 for ; Fri, 16 Nov 2012 13:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-1] 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 jEXz-MsmV42l for ; Fri, 16 Nov 2012 13:12:13 -0800 (PST) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) by ietfa.amsl.com (Postfix) with ESMTP id C001621F8956 for ; Fri, 16 Nov 2012 13:12:12 -0800 (PST) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id qAGLBqVU016530 for ; Fri, 16 Nov 2012 21:12:12 GMT Received: by mail-qc0-f169.google.com with SMTP id t2so1932241qcq.28 for ; Fri, 16 Nov 2012 13:11:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:organization:user-agent; bh=z45ELDgNyb1OPWM5sl5/4x+TFVivXq9rGVIAcuG1kLQ=; b=hGqrmApFWz7Cn778431i91/0s/IiUOHavrwPh97Gq+c5v0bXSqGVwFybevq0HqAWtW 2wQgtOvSVMNjvXb3DqUpbHtT4W+NZ4k7h0Gx6YQ1/qRqeqzXihvUOo+NE6v70xj2yqzg DUM3z0F+r3ppMX3Y929itWNObsyGdSoA4Oc+2wIozXm5OmvreLI2rZbz1EoHS0PtnR8S 2faXllvS1+4/MBsLyTPwkf0RYHCSLxK4gmpqKPNEwE+HsRxAorJcb3GDY8Py6oz/CVAW S70FbGEGTdFpFWJj0MKBW08MD3W4xfDMGkLsL+pLTWBS2GSyH5eiw2XY+I6hjZ83Z5xX nP/w== Received: by 10.49.82.68 with SMTP id g4mr6232410qey.54.1353100311755; Fri, 16 Nov 2012 13:11:51 -0800 (PST) Received: from w3.org (c-76-24-31-179.hsd1.ma.comcast.net. [76.24.31.179]) by mx.google.com with ESMTPS id fh6sm1795146qab.19.2012.11.16.13.11.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Nov 2012 13:11:50 -0800 (PST) Sender: "Eric Prud'hommeaux" Date: Fri, 16 Nov 2012 16:11:48 -0500 From: "Eric Prud'hommeaux" To: Yakov Shafranovich Message-ID: <20121116211146.GD11584@w3.org> References:

<50A5CE66.4020608@it.aoyama.ac.jp> <20121116145116.GB3174@w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: World Wide Web Consortium (W3C) - http://www.w3.org/ User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Fri, 16 Nov 2012 21:12:12 +0000 (UTC) Cc: Martin =?utf-8?B?Si4gRMO8cnN0?= , media-types@iana.org Subject: Re: [media-types] New media registration request: application/sql X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 21:12:14 -0000 * Yakov Shafranovich [2012-11-16 14:45-0500] > On Fri, Nov 16, 2012 at 9:51 AM, Eric Prud'hommeaux wrote: > > * Yakov Shafranovich [2012-11-16 08:04-0500] > >> On Fri, Nov 16, 2012 at 12:25 AM, "Martin J. Dürst" > >> wrote: > >> > Hello Yakov, > >> > > >> > > >> > On 2012/11/16 12:46, Yakov Shafranovich wrote: > >> >> Encoding considerations: > >> >> > >> >> While SQL uses US-ASCII by default, some implementations may use > >> >> other encodings including [Unicode]. > >> > > >> > > >> > How are these encodings indicated? If there's no way to indicate them, > >> > that's a bad idea (interoperability failure), and should be avoided. > >> > > >> > Regards, Martin. > >> > >> Thanks for the comment! > >> > >> Would adding "charset" as an optional parameter to indicate encoding > >> help to resolve this? > > > > I believe this would be one path to ameliorating the pain of issuing > > DDL and SQL requests. Creating UTF-8 tables and insert non-ascii data > > is done entirely differently with e.g. Postgres, Oracle and MySQL. I > > would applaud any efforts to improve this. > > > > The downside of permitting a charset parameter with an arbitrary > > charset parameter is that server interfaces must then accept an > > arbitrary set of character encodings, passing them on to the server in > > the same encoding, if the server supports that encoding¹, or > > transcoding to a supported encoding. To give a scale of this > > implementation burden, > > > > describes more than 50 as "common" character encodings. > > > > ¹ This is complicated by the fact that tables created with one > > encoding may not support INSERTs, DELETEs, SELECTs in another > > encoding. > > > > The XML approach to solving this was to mandate that UTF-8 and UTF-16 > > MUST be supported (see ). This > > complicates parsers by demanding relatively complex encoding detection > > heuristics and byte-order markers. > > > > A simpler approach was used by e.g. text/turtle, which mandated one > > encoding: > > [[ > > Optional parameters: > > charset — this parameter is required when transferring non-ASCII > > data. If present, the value of charset is always UTF-8. > > ]] — > > > > This simplifies parsing and reduces (or frequently liminates) the > > transcoding requirements. > > > > Considering these schemes in light of an SQL agent G issuing a query > > to a service S, the choices are: > > > > do nothing: G can only count on S to handle requests entirely in > > ASCII. Any non-ASCII treatment would be outside of the spec. > > > > arbitrary charset: G must find out by external means what encodings > > are supported by S. At that point, non-ASCII messages are in-spec > > and indicated by the charset parameter. > > > > guaranteed charsets: G can count on S accepting the guaranteed > > encodings. Other encodings would have to be negotiated as above. > > > > fixed charset: G must submit requests the appropriate encoding. (If > > G is accepting user input from e.g. KOI8R, the burden of transcoding > > is on G.) > > > > If not already apparent, I support the fixed charset approach. > > Thanks for that information. I think I am going to do a survey of what > the major database systems in order to see if it is feasible to settle > on a fixed character set or a subset of encodings. I suspect your thinking is that picking a media type that most SQL servers already support is likely to minimize the transcoding required when SQL servers or 3rd party tools accept text/sql or app/sql queries. > > I also urge you to register text/sql instead of application/sql. > > > > My impression has been that programming languages are usually > registered under the "application" tree as opposed to the "text" tree. > As per (http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-14#section-4.2.5): > > "The "application" top-level type is to be used for discrete data that > do not fit under any of the other type names, and particularly for > data to be processed by some type of application program." > > and > > "Expected uses for the "application" type name include but are not > limited to file transfer, spreadsheets, presentations, scheduling > data, and languages for "active"(computational) material." > > A quick perusal of the "text" tree shows that other than CSS and HTML, > most languages are registered under "application". The closest example > to SQL is perhaps SPARQL which is also registered under "application". Yes, which I regret. A common metric is "would your average geek want to edit this content with a generic text editor?". Another is "would your average geek want this content saved to disk vs. rendered as text in a web browser". (Some people extend that to "would your average web user ...", though they are unlikely to be clicking on a link.) It drives me crazy that the primary consumers of some media have to go hunt for it in a Downloads directory rather than simply seeing it displayed. For example, the most likely person to click on a app/sparql link is someone who's expecting to read that SPARQL. > Yakov -- -ericP From yakov@shaftek.org Sat Nov 17 18:46:26 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE4721F84D3 for ; Sat, 17 Nov 2012 18:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-1] 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 knuqcI3WF92m for ; Sat, 17 Nov 2012 18:46:25 -0800 (PST) Received: from pechora3.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6BB21F8658 for ; Sat, 17 Nov 2012 18:46:25 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id qAI2k4Am031087 for ; Sun, 18 Nov 2012 02:46:24 GMT Received: by mail-ie0-f169.google.com with SMTP id 10so5097358ied.28 for ; Sat, 17 Nov 2012 18:46:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=UncIvUWzH4hu5jVZ1YAckjm5ZVIL02P9lrmHhAc1Oo0=; b=dV+zDFk0GtIfDdvZXaepf0wXLdKztNQZP29mxPrPWTv+Whq9RAc/Ty04Rd4nE8D9+x 2BAVK/g0rY59aUGLIa44/dt0Pp8PGu3jrFmUXzUiZmFe//edZvTS+B06Ia2r/fxmKQpo y7nIy5s8Y9e+FGsA+D9HcBYB2ogeLOq23G+pGATLHf4xl61/pSHeZpTDt61nsZzQd+vv P7N3Ki951N8k0ViDIXLavrDgIVlQFi6MfdmhO2yik4TXwMzCXgC+YbfHkBeOaKNXy32+ KfUgbVSx0VQkX2MUtWeLN8kktMVKngXzlLXGo4rTf2q//atAJ+vBNwmWp23i+AF7SbZ9 IXbg== Received: by 10.50.57.225 with SMTP id l1mr3318993igq.37.1353206764287; Sat, 17 Nov 2012 18:46:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.106.98 with HTTP; Sat, 17 Nov 2012 18:45:33 -0800 (PST) X-Originating-IP: [98.140.248.199] In-Reply-To: <20121116211146.GD11584@w3.org> References:

<50A5CE66.4020608@it.aoyama.ac.jp> <20121116145116.GB3174@w3.org> <20121116211146.GD11584@w3.org> From: Yakov Shafranovich Date: Sat, 17 Nov 2012 21:45:33 -0500 Message-ID: To: "Eric Prud'hommeaux" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlrH55aojrNLZSHgasrOJU9FLDFUHKQ3gjZw5fbdrcb5Ghb8nVtSfi9HS3Dr+w8fTYt3sQ8 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Sun, 18 Nov 2012 02:46:25 +0000 (UTC) Cc: media-types@iana.org Subject: Re: [media-types] New media registration request: application/sql X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 02:46:26 -0000 On Fri, Nov 16, 2012 at 4:11 PM, Eric Prud'hommeaux wrote: > > I suspect your thinking is that picking a media type that most SQL > servers already support is likely to minimize the transcoding required > when SQL servers or 3rd party tools accept text/sql or app/sql queries. > We are sort of limited here with what we can do. Registration of a media type that references an existing standard cannot mandate what encoding should or should not be used that would conflict with that standard. I actually dug into the SQL standard and found a section discussing encodings (ISO/IEC 9075-2:2011, section 4.2.4). It seems that the ISO standard for SQL mandates the following encodings to be supported by all implementations: o GRAPHIC_IRV is the character encoding form in which the coded representation of each character is specified in [ISO646]. o LATIN1 is the character encoding form specified in [ISO8859-1]. o ISO8BIT is the character encoding form specified in [ISO8859-1], augmented by [ISO6429]. When restricted to the LATIN1 characters, it is the same character encoding form as LATIN1. o UTF32 is the character encoding form specified in [ISO10646], in which each character is encoded as four octets. o UTF16 is the character encoding form specified in [ISO10646], in which each character is encoded as two or four octets. o UTF8 is the character encoding form specified in [ISO10646], in which each character is encoded as from one to four octets. It also states that: The precedence of character encoding forms applicable to the UCS character repertoire and defined in this part of ISO/IEC 9075 is: UTF8 =E2=89=BA UTF16 =E2=89=BA UTF32 There are also three implementation-specific encodings which aren't relevant here (SQL_CHARACTER, SQL_TEXT and SQL_IDENTIFIER) It sounds like the following ones are supported by all implementations and should be portable: US-ASCII ISO8859-1 UTF8 UTF16 UTF32 It sounds like we can specify the optional "charset" parameter and allow US-ASCII to be the default. We can also list the other ones as the ones that would be possible choices and are portable across all implementations. Any other charset would be supported only if the implementation in question supports it. I would also add a section to the draft discussing this entire thing. >> > I also urge you to register text/sql instead of application/sql. >> > >> ... >> >> A quick perusal of the "text" tree shows that other than CSS and HTML, >> most languages are registered under "application". The closest example >> to SQL is perhaps SPARQL which is also registered under "application". > > Yes, which I regret. > > A common metric is "would your average geek want to edit this content > with a generic text editor?". Another is "would your average geek want > this content saved to disk vs. rendered as text in a web browser". > (Some people extend that to "would your average web user ...", though > they are unlikely to be clicking on a link.) It drives > me crazy that the primary consumers of some media have to go hunt for > it in a Downloads directory rather than simply seeing it displayed. > For example, the most likely person to click on a app/sparql link is > someone who's expecting to read that SPARQL. > Unfortunately, I am constrained by the current registration procedures as defined in RFC 4289 and draft-ietf-appsawg-media-type-regs-14. From those it seems that the best place for this media type would be under the "application" tree. Yakov From liam@w3.org Sat Nov 17 19:31:40 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDC021F8431 for ; Sat, 17 Nov 2012 19:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.14 X-Spam-Level: X-Spam-Status: No, score=-8.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-8] 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 MNJ12au4qcUZ for ; Sat, 17 Nov 2012 19:31:38 -0800 (PST) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) by ietfa.amsl.com (Postfix) with ESMTP id 406BB21F842A for ; Sat, 17 Nov 2012 19:31:37 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id qAI3VGHu025412 for ; Sun, 18 Nov 2012 03:31:36 GMT Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1TZvbC-0005bM-RI; Sat, 17 Nov 2012 22:31:11 -0500 From: Liam R E Quin To: "Eric Prud'hommeaux" In-Reply-To: <20121116211146.GD11584@w3.org> References:

<50A5CE66.4020608@it.aoyama.ac.jp> <20121116145116.GB3174@w3.org> <20121116211146.GD11584@w3.org> Content-Type: text/plain; charset="ISO-8859-15" Organization: W3C - World Wide Web Consortium Date: Sat, 17 Nov 2012 22:30:06 -0500 Message-ID: <1353209406.4860.300.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2-2.mga1 Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Sun, 18 Nov 2012 03:31:36 +0000 (UTC) Cc: "Martin J. =?ISO-8859-1?Q?D=FCrst?=" , Yakov Shafranovich , media-types@iana.org Subject: Re: [media-types] New media registration request: application/sql X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: liam@w3.org List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 03:31:40 -0000 On Fri, 2012-11-16 at 16:11 -0500, Eric Prud'hommeaux wrote: > > A quick perusal of the "text" tree shows that other than CSS and HTML, > > most languages are registered under "application". The closest example > > to SQL is perhaps SPARQL which is also registered under "application". > > Yes, which I regret. > > A common metric is "would your average geek want to edit this content > with a generic text editor?". Another is "would your average geek want > this content saved to disk vs. rendered as text in a web browser". It used to be that text/* was subject to CR LF processing and to translation of encodings by proxies. This is part of why XML moved from text/xml to application/xml - a rewriting proxy could not be expected to change the XML encoding declaration inside the data stream. (I say "used to be" because I'm not sure it's as common these days) However, given that the registration already says that SQL should only be exchanged over a trusted connection, I don't think proxies come into consideration. > It drives > me crazy that the primary consumers of some media have to go hunt for > it in a Downloads directory rather than simply seeing it displayed. This is a function of browsers, not of MIME content type headers. For example, I frequently have to empty my Download "folder" out because every PDF file gets saved there even if I didn't want to keep it. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml Co-author, 5th edition of "Beginning XML", Wrox, Summer 2012 From ericw3c@gmail.com Sun Nov 18 08:16:16 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A7A21F84F9 for ; Sun, 18 Nov 2012 08:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-1] 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 eF6Oa3RjZNGa for ; Sun, 18 Nov 2012 08:16:14 -0800 (PST) Received: from pechora3.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB0E21F84EC for ; Sun, 18 Nov 2012 08:16:11 -0800 (PST) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id qAIGFoS6027622 for ; Sun, 18 Nov 2012 16:16:10 GMT Received: by mail-qa0-f48.google.com with SMTP id s11so2504269qaa.7 for ; Sun, 18 Nov 2012 08:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:organization :user-agent; bh=TR1h02rL7YMueRPtKYE1ytVNw1sGp5ZshEpJl3XWYTM=; b=DdBmUXc9bdu0koLrFmLTF3r+KJ6klCbihJrdHuQPzikPyXR4MOD52naqXUVKybdeKh 9/jRRHTbmQSHRQCHBMMnQIq+Kh8+ar5fWHMLs/dq2WcdyD6rjaxBSr5CnV60AQvGmyfR 8j8BHIy+83WBaKR2oZBGrtWfw5GQ1szIfRCNSaX8ZiCXH0l1S9/MqhdTD6pbysByFLoX YuQU3P5YFeakJxfKww/SzIPzDvXII9wkn+7Re5gBmlnwrxvaNIv0fS2dB0MK53p+2Bej rYTi3ca2IWz5wTn6PNOp+6NmGaN122d2COPmaCDxH217y8lL0dCcqku0XbRe3hS+7v/9 6jKg== Received: by 10.224.174.70 with SMTP id s6mr9522967qaz.60.1353255350441; Sun, 18 Nov 2012 08:15:50 -0800 (PST) Received: from w3.org (c-76-24-31-179.hsd1.ma.comcast.net. [76.24.31.179]) by mx.google.com with ESMTPS id i9sm4683248qak.3.2012.11.18.08.15.48 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Nov 2012 08:15:49 -0800 (PST) Sender: "Eric Prud'hommeaux" Date: Sun, 18 Nov 2012 11:15:47 -0500 From: "Eric Prud'hommeaux" To: Liam R E Quin Message-ID: <20121118161545.GF11584@w3.org> References:

<50A5CE66.4020608@it.aoyama.ac.jp> <20121116145116.GB3174@w3.org> <20121116211146.GD11584@w3.org> <1353209406.4860.300.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1353209406.4860.300.camel@localhost.localdomain> Organization: World Wide Web Consortium (W3C) - http://www.w3.org/ User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Sun, 18 Nov 2012 16:16:11 +0000 (UTC) Cc: Martin =?utf-8?B?Si4gRMO8cnN0?= , Yakov Shafranovich , media-types@iana.org Subject: Re: [media-types] New media registration request: application/sql X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 16:16:16 -0000 * Liam R E Quin [2012-11-17 22:30-0500] > On Fri, 2012-11-16 at 16:11 -0500, Eric Prud'hommeaux wrote: > > > > A quick perusal of the "text" tree shows that other than CSS and HTML, > > > most languages are registered under "application". The closest example > > > to SQL is perhaps SPARQL which is also registered under "application". > > > > Yes, which I regret. > > > > A common metric is "would your average geek want to edit this content > > with a generic text editor?". Another is "would your average geek want > > this content saved to disk vs. rendered as text in a web browser". > > It used to be that text/* was subject to CR LF processing and to > translation of encodings by proxies. This is part of why XML moved from > text/xml to application/xml - a rewriting proxy could not be expected to > change the XML encoding declaration inside the data stream. I don't see this as an argument agasint text/sql (or text/sparql-query) in that SQL has no built-in media type label. A generic proxy would could do the right thing without having to do any subtype-dependent parsing/manipulation. > (I say "used to be" because I'm not sure it's as common these days) Yeah, HTML shouldn't be in text/ 'cause of this, c.f. > However, given that the registration already says that SQL should only > be exchanged over a trusted connection, I don't think proxies come into > consideration. I was going to bring that up as well. The current Security considerations includes: [[ Implementors and users are encouraged only to exchange SQL files among trusted parties ]] which is pretty much the state of the art today. Whenever I want to execute an SQL query or update, I find a db-specific driver, issue a ODBC/JDBC/DBD or db-specific connect call, concoct some DB-specific SQL, and parse the results in a DB-specific way. There's a thriving industry making a living off of these incompatibilities and there's no competing pressure towards a standard protocol with compliant SQL. A trivial use of an SQL media type would be to "view source". In this case, anyone would be encouraged to *exchange* SQL, but be judicious about executing it. A real advancement would be to define a media type which encouraged either 3rd party tools or the RDBs themselves to consume valid SQL passed via a small number (potentially one) of encodings. This would encourage implementors to add alternate parsers (I added a SPARQL parser to MySQL and the Drizzle folks want to do the same for a compliant SQL parser) and generally reduce the burden of using SQL. Of course, vendor-specific protocols tend to be nicely optimized, but most of us don't need such bit squeezing, and no one needs it on day one of a project. > > It drives > > me crazy that the primary consumers of some media have to go hunt for > > it in a Downloads directory rather than simply seeing it displayed. > > This is a function of browsers, not of MIME content type headers. > For example, I frequently have to empty my Download "folder" out because > every PDF file gets saved there even if I didn't want to keep it. I agree that your miscreant browser is doing the wrong thing, but I think it's only applicable here as an example of one annoyance that could emerge from putting sql under the application/ tree. (Presumably your browser has a handler for application/pdf, saves the file, calls the handler, and then fails to reap the file.) > Liam > > > -- > Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ > Pictures from old books: http://fromoldbooks.org/ > Ankh: irc.sorcery.net irc.gnome.org freenode/#xml > Co-author, 5th edition of "Beginning XML", Wrox, Summer 2012 > -- -ericP From ned.freed@mrochek.com Sun Nov 18 10:41:27 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408A421F8472 for ; Sun, 18 Nov 2012 10:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, J_CHICKENPOX_48=0.6] 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 Mz7jqWBecuwE for ; Sun, 18 Nov 2012 10:41:26 -0800 (PST) Received: from pechora6.dc.icann.org (unknown [IPv6:2620:0:2830:201::1:72]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6E321F846C for ; Sun, 18 Nov 2012 10:41:25 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by pechora6.dc.icann.org (8.13.8/8.13.8) with ESMTP id qAIIf0cr022160 for ; Sun, 18 Nov 2012 18:41:22 GMT Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMRK82W2VK001VBU@mauve.mrochek.com> for media-types@iana.org; Sun, 18 Nov 2012 10:35:37 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMQP7JGKK000008T@mauve.mrochek.com>; Sun, 18 Nov 2012 10:35:33 -0800 (PST) Message-id: <01OMRK805A8G00008T@mauve.mrochek.com> Date: Sun, 18 Nov 2012 10:26:40 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sat, 17 Nov 2012 22:30:06 -0500" <1353209406.4860.300.camel@localhost.localdomain> MIME-version: 1.0 Content-type: TEXT/PLAIN References:

<50A5CE66.4020608@it.aoyama.ac.jp> <20121116145116.GB3174@w3.org> <20121116211146.GD11584@w3.org> <1353209406.4860.300.camel@localhost.localdomain> To: Liam R E Quin X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora6.dc.icann.org [192.0.46.72]); Sun, 18 Nov 2012 18:41:23 +0000 (UTC) Cc: Eric Prud'hommeaux , Yakov Shafranovich , "Martin J. =?ISO-8859-1?Q?D=FCrst?=" , media-types@iana.org Subject: Re: [media-types] New media registration request: application/sql X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 18:41:27 -0000 > On Fri, 2012-11-16 at 16:11 -0500, Eric Prud'hommeaux wrote: > > > A quick perusal of the "text" tree shows that other than CSS and HTML, > > > most languages are registered under "application". The closest example > > > to SQL is perhaps SPARQL which is also registered under "application". > > > > Yes, which I regret. > > > > A common metric is "would your average geek want to edit this content > > with a generic text editor?". Another is "would your average geek want > > this content saved to disk vs. rendered as text in a web browser". > It used to be that text/* was subject to CR LF processing and to > translation of encodings by proxies. Depending on the protocol/transport, it still is. > This is part of why XML moved from > text/xml to application/xml - a rewriting proxy could not be expected to > change the XML encoding declaration inside the data stream. Another issue is that line terminators are supposed to be 0d0a and nothing else in text types. > (I say "used to be" because I'm not sure it's as common these days) > However, given that the registration already says that SQL should only > be exchanged over a trusted connection, I don't think proxies come into > consideration. But the real question is why would you want for SQL to be under text to begin with. I really don't see a reason for it. Just register it under application and be done with it. That also lets you avoid all the issues with charset parameters. > > It drives > > me crazy that the primary consumers of some media have to go hunt for > > it in a Downloads directory rather than simply seeing it displayed. > This is a function of browsers, not of MIME content type headers. > For example, I frequently have to empty my Download "folder" out because > every PDF file gets saved there even if I didn't want to keep it. Exactly. If you want material of a given type to be handled in a particular way, that's between you and your browser. Types tell you what some thing is, they don't say how to handle it. Unfortunately browsers seem to be getting worse in regard to flexible handling of different types. But if there's something that can be done about it from a type registration perspective, I for one have no idea what it is. Ned From yakov@shaftek.org Sun Nov 18 10:48:21 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D3121F8434 for ; Sun, 18 Nov 2012 10:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-1] 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 VcgCrY75mQk6 for ; Sun, 18 Nov 2012 10:48:20 -0800 (PST) Received: from pechora8.dc.icann.org (unknown [IPv6:2620:0:2830:201::1:74]) by ietfa.amsl.com (Postfix) with ESMTP id ABD3521F8432 for ; Sun, 18 Nov 2012 10:48:20 -0800 (PST) Received: from mail-vb0-f41.google.com (mail-vb0-f41.google.com [209.85.212.41]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id qAIIlxaA001916 for ; Sun, 18 Nov 2012 18:48:20 GMT Received: by mail-vb0-f41.google.com with SMTP id v13so4103543vbk.28 for ; Sun, 18 Nov 2012 10:47:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=DQxSPSrpIiIapZ0Zw5vQVokn8ShW3Z7ZDTd13+BQh14=; b=hQK1iyE2gc13ewdfDzHd3EoQ3fkVQhxT4REbtPlfmh0i3VdkQEGIgye6sv6iC3/r2F DftWVBT36lpb+Zjh6zj0uk9GEtuA0S1Ha7kIEjh9DG465ecPU8Pm/LWkgShrMaqpTQTP KTQlBZ+1xzitGJlirkhkOO8zcBdddal9ja9IDDaXwbb8Ca3G1yG+abH0Ze/7ipgyyiJ0 WDAepte3lvRnC4uuRGSbHIxoXG4BQC3oVH5G3ZPcl01KrRIWLjq+q/XRrGLQSkQSHVA3 76d12pjdIP+P4ORUNFPF/g2rPk8cSAjdFtaVrYriwihpl1gyx86W7Ep4UyRWDF2t8bNW KtOw== Received: by 10.58.67.199 with SMTP id p7mr14317327vet.40.1353264479405; Sun, 18 Nov 2012 10:47:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.209.134 with HTTP; Sun, 18 Nov 2012 10:47:29 -0800 (PST) X-Originating-IP: [98.140.248.199] In-Reply-To: <01OMRK805A8G00008T@mauve.mrochek.com> References:

<50A5CE66.4020608@it.aoyama.ac.jp> <20121116145116.GB3174@w3.org> <20121116211146.GD11584@w3.org> <1353209406.4860.300.camel@localhost.localdomain> <01OMRK805A8G00008T@mauve.mrochek.com> From: Yakov Shafranovich Date: Sun, 18 Nov 2012 13:47:29 -0500 Message-ID: To: Ned Freed Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkIObnz48m3g9uWpigC1f4I+3ubWVwKKmCnWB5uaqaYoKe4oWMfosoMVor4dZyCicR9TJ3n X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Sun, 18 Nov 2012 18:48:20 +0000 (UTC) Cc: media-types@iana.org Subject: Re: [media-types] New media registration request: application/sql X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 18:48:21 -0000 On Sun, Nov 18, 2012 at 1:26 PM, Ned Freed wrote: >> On Fri, 2012-11-16 at 16:11 -0500, Eric Prud'hommeaux wrote: > >> However, given that the registration already says that SQL should only >> be exchanged over a trusted connection, I don't think proxies come into >> consideration. > > But the real question is why would you want for SQL to be under text to begin > with. I really don't see a reason for it. Just register it under application > and be done with it. That also lets you avoid all the issues with charset > parameters. > How would registration under "application" avoid issues with charset? We would still need to document how encodings are handled. Yakov From ned.freed@mrochek.com Mon Nov 19 05:22:28 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF0421F85E0 for ; Mon, 19 Nov 2012 05:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, J_CHICKENPOX_48=0.6] 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 glhzDzp8ISse for ; Mon, 19 Nov 2012 05:22:28 -0800 (PST) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id C89BE21F8564 for ; Mon, 19 Nov 2012 05:22:21 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id qAJDLxrW001332 for ; Mon, 19 Nov 2012 13:22:19 GMT Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMSND90TJ40020EE@mauve.mrochek.com> for media-types@iana.org; Mon, 19 Nov 2012 05:16:52 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMGB2WUMLC00008S@mauve.mrochek.com>; Mon, 19 Nov 2012 05:16:49 -0800 (PST) Message-id: <01OMSND6RZYK00008S@mauve.mrochek.com> Date: Mon, 19 Nov 2012 05:13:44 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 18 Nov 2012 13:47:29 -0500" MIME-version: 1.0 Content-type: TEXT/PLAIN References:

<50A5CE66.4020608@it.aoyama.ac.jp> <20121116145116.GB3174@w3.org> <20121116211146.GD11584@w3.org> <1353209406.4860.300.camel@localhost.localdomain> <01OMRK805A8G00008T@mauve.mrochek.com> To: Yakov Shafranovich X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Mon, 19 Nov 2012 13:22:19 +0000 (UTC) Cc: Ned Freed , media-types@iana.org Subject: Re: [media-types] New media registration request: application/sql X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 13:22:29 -0000 > On Sun, Nov 18, 2012 at 1:26 PM, Ned Freed wrote: > >> On Fri, 2012-11-16 at 16:11 -0500, Eric Prud'hommeaux wrote: > > > >> However, given that the registration already says that SQL should only > >> be exchanged over a trusted connection, I don't think proxies come into > >> consideration. > > > > But the real question is why would you want for SQL to be under text to begin > > with. I really don't see a reason for it. Just register it under application > > and be done with it. That also lets you avoid all the issues with charset > > parameters. > > > How would registration under "application" avoid issues with charset? Application has none of the baggage associated with default behavior in the absence of a parameter. See RFC 6657. > We would still need to document how encodings are handled. Of course. But you can do that free of any entanglements with the top-level type. Ned From eric.turcotte@ericsson.com Mon Nov 19 07:21:08 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B503721F8678 for ; Mon, 19 Nov 2012 07:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.444 X-Spam-Level: X-Spam-Status: No, score=-4.444 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-4] 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 a9VVUACqr17R for ; Mon, 19 Nov 2012 07:21:08 -0800 (PST) Received: from pechora3.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id C5ED521F8667 for ; Mon, 19 Nov 2012 07:21:07 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id qAJFKlLx021909 for ; Mon, 19 Nov 2012 15:21:07 GMT Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qAJF70xP031211; Mon, 19 Nov 2012 09:07:02 -0600 Received: from EUSAAHC001.ericsson.se (147.117.188.75) by eusaamw0712.eamcs.ericsson.se (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 19 Nov 2012 10:00:02 -0500 Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0318.001; Mon, 19 Nov 2012 10:00:02 -0500 From: Eric Turcotte To: Ned Freed Thread-Topic: [media-types] MIME Type registration Thread-Index: AQHNxB0UwchX+C79vk+NhPupAdin15fxPKRw Date: Mon, 19 Nov 2012 15:00:02 +0000 Message-ID: <918C98C9EE8A0C489EB362DC13E0D60301B0E2@eusaamb101.ericsson.se> References: <918C98C9EE8A0C489EB362DC13E0D6030161D8@EUSAAMB101.ericsson.se> <01OMOOFANQW400008S@mauve.mrochek.com> In-Reply-To: <01OMOOFANQW400008S@mauve.mrochek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Greylist: Delayed for 00:20:41 by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Mon, 19 Nov 2012 15:21:07 +0000 (UTC) Cc: "media-types@iana.org" Subject: Re: [media-types] MIME Type registration X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 15:21:08 -0000 Dear Ned, Thanks for your comments. Please see my reply below [et nov 19]. BR, Eric.=20 -----Original Message----- From: Ned Freed [mailto:ned.freed@mrochek.com]=20 Sent: November-16-12 12:01 PM To: Eric Turcotte Cc: media-types@iana.org Subject: Re: [media-types] MIME Type registration A couple of comments... > Hi, > I would like to register (in the standards tree) a new MIME type that has= been defined in 3GPP working group SA4. The 3GPP specification where this = is defined is: > http://www.3gpp.org/ftp/Specs/archive/26_series/26.346/26346-980.zip. > In that sepecification, section C.14 has the MIME type registration infor= mation, and is extracted bellow for your consideration/review. > Please let me know if additional information or questions you may have. > Thank you, > Eric Turcotte > C.14 Registration of MIME type "application/mbms-schedule+xml" > The MIME-Type registration for "application/mbms-schedule+xml" identifies= XML documents that follows the schema " urn:3gpp:metadata:2011:MBMS:schedu= leDescription " defined in clause 11.2A.2. > Type name: application > Subtype name: mbms-schedule+xml > Required parameters: > None > Optional parameters: > charset: As specified in RFC 3023 [83] for media type application/xml. > Encoding considerations: > This is an XML document and the encoding considerations are the same=20 > as for media type "application/xml" defined in RFC 3023 [83]. It's fine to add this, but you still need to specify the encoding. If the t= ype is limited to utf-8 and similar charsets 8bit is appropriate, if utf-16 variants are allowed it needs to be binary. =3D=3D=3D=3D=3D=3D=3D=3D=3D [et nov 19] The encoding is limited to UTF-8 so it should be 8bit as you me= ntion. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Security considerations: > The information present in this media format is used to configure the=20 > receiving application. Thus the usage of the fomat is vulnerable to=20 > attacks modifying or spoofing the content of this format. It is=20 > recommended to use source authentication and integrity protection. You should also comment on any need, or the lack of any need, for privacy p= rotection. That is, does this configuration information contain passwords o= r keys similar things? =3D=3D=3D=3D=3D=3D=3D=3D=3D [et nov 19] No there is no need for privacy protection, as the configuratio= n information does not contain passwords or keys or similar. Would you be OK with the following text (adding 1 sentence at the end? The information present in this media format is used to configure the recei= ving application. Thus the usage of the fomat is vulnerable to attacks modi= fying or spoofing the content of this format. It is=20 recommended to use source authentication and integrity protection. The info= rmation carried in the media format does not contain any private informatio= n such as passwords or keys. =3D=3D=3D=3D=3D=3D=3D=3D=3D > Interoperability considerations: > None > Published specification: > 3GPP TS 26.346 > Applications which use this media type: > 3GPP MBMS based applications > Additional information: > Magic number(s): None > File extension(s): > Macintosh file type code(s): > Person & email address to contact for further information: > Eric Turcotte (Eric.Turcotte@ericsson.com) 3GPP TSG SA WG4 > Intended usage: COMMON > Restrictions on usage: > None > Author: > 3GPP TSG SA WG4 > Change controller: > 3GPP TSG SA WG4 Ned From enrico.marocco@telecomitalia.it Mon Nov 19 07:47:16 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0EF21F8639 for ; Mon, 19 Nov 2012 07:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.391 X-Spam-Level: X-Spam-Status: No, score=-100.391 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 m8vz6f3m0wgZ for ; Mon, 19 Nov 2012 07:47:15 -0800 (PST) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id 64D6621F8593 for ; Mon, 19 Nov 2012 07:47:15 -0800 (PST) Received: from grfhub702rm001.griffon.local (10.19.3.9) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.3.279.5; Mon, 19 Nov 2012 16:47:10 +0100 Received: from MacLab.local (163.162.180.246) by smtp.telecomitalia.it (10.19.9.235) with Microsoft SMTP Server (TLS) id 8.3.279.5; Mon, 19 Nov 2012 16:47:10 +0100 Message-ID: <50AA547D.2020002@telecomitalia.it> Date: Mon, 19 Nov 2012 16:47:09 +0100 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <508E964B.5060006@telecomitalia.it> <50924C0F.9050308@it.aoyama.ac.jp> In-Reply-To: <50924C0F.9050308@it.aoyama.ac.jp> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030701020803010901090909" X-TI-Disclaimer: Disclaimer1 Cc: "media-types@ietf.org" , "draft-ietf-alto-protocol@tools.ietf.org" , Martin Stiemerling Subject: Re: [media-types] Media type review for draft-ietf-alto-protocol-13 X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 15:47:16 -0000 --------------ms030701020803010901090909 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin, all, apologies for an overly vague request, and for a response time closer to deep space rather than human communications. IETF meeting and day job took the upper hand, my bad. Let me try again. The ALTO protocol has been specified in the ALTO WG, initially in APP and later in TSV. The main design choices had been made with the contribution of several APPs experts (Peter S-A is officially the technical advisor of the group), but their supervision has weakened with time. It would thus be very useful to have a review of the key parts, including the media type registration part, now that the WG considers the draft ready, but before submitting it to the IESG. The document is draft-ietf-alto-protocol-13. It is available at http://tools.ietf.org/html/draft-ietf-alto-protocol-13 The registration request, for 10 "application/alto-*+json" media types, is in section 9.1: http://tools.ietf.org/html/draft-ietf-alto-protocol-13#section-9.1 If anyone on this list could spend a few minutes even only for a sanity check, that would be very useful and extremely appreciated. Enrico On 11/1/12 11:16 AM, "Martin J. D=C3=BCrst" wrote: > Hello Enrico, >=20 > This is a standing comment of mine: Please send the actual registration= =20 > template to the media-types@ietf.org list, not just a pointer to a draf= t=20 > (in your case not even an URI, so it's not directly "actionable"). >=20 > This increases the chance of getting relevant comments significantly. >=20 > Regards, Martin. >=20 > On 2012/10/29 23:44, Enrico Marocco wrote: >> Hi, >> >> as document shepherd, I would kindly request a review on the media typ= e >> registration part of draft-ietf-alto-protocol-13 that is about to be >> submitted to the IESG for publication. >> >> Thank you in advance! >> >> Enrico >> >> >> >> >> _______________________________________________ >> media-types mailing list >> media-types@ietf.org >> https://www.ietf.org/mailman/listinfo/media-types --------------ms030701020803010901090909 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/ 5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0 UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2 aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6 R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjExMTkx NTQ3MDlaMCMGCSqGSIb3DQEJBDEWBBQhogkacrYvJ46M+4eOeRmzWWhR7DBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEAP0QXhWfIO+A9ckTK4iu2cakwapB3gDIg/DxDDXTd tzD86TLXifTh+wtXDfYUswxT4h9tOJNEdetJs8w1zweVFQvM9x4i/mhaLkGQt+4U2o5lcW5q xe2DQGjcC5LhBliLoV+iB4l1ECcGWQiA3YRd+dv40293EMpPdVtafuuVNyMqkz3fzWZCZDRB 8jxOwNuKnR3+rrMGf0Vaay0gNJnQB74tq3OMI1uUR5ck2tr0kVTC2fSofJk/6uety1qFQ/hs HAPvyVzqsQvvx+yRFrtRdHzDOWoGzCCMLJPOFHV9n8WRixlQqqpj+0P5pnPYHiSy3n+0+vl2 gHORIglAlQGZeQAAAAAAAA== --------------ms030701020803010901090909-- From ned.freed@mrochek.com Mon Nov 19 09:08:52 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3510E21F8549 for ; Mon, 19 Nov 2012 09:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=-0.951, BAYES_00=-2.599, FRT_BELOW2=2.154] 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 FbmDGvJ+Hh-6 for ; Mon, 19 Nov 2012 09:08:51 -0800 (PST) Received: from pechora6.dc.icann.org (unknown [IPv6:2620:0:2830:201::1:72]) by ietfa.amsl.com (Postfix) with ESMTP id 49CF521F8683 for ; Mon, 19 Nov 2012 09:08:51 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by pechora6.dc.icann.org (8.13.8/8.13.8) with ESMTP id qAJH8QEs016652 for ; Mon, 19 Nov 2012 17:08:47 GMT Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMSVA29SG0001Z7M@mauve.mrochek.com> for media-types@iana.org; Mon, 19 Nov 2012 09:03:22 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMGB2WUMLC00008S@mauve.mrochek.com>; Mon, 19 Nov 2012 09:03:18 -0800 (PST) Message-id: <01OMSV9ZXS4800008S@mauve.mrochek.com> Date: Mon, 19 Nov 2012 08:58:47 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 19 Nov 2012 15:00:02 +0000" <918C98C9EE8A0C489EB362DC13E0D60301B0E2@eusaamb101.ericsson.se> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <918C98C9EE8A0C489EB362DC13E0D6030161D8@EUSAAMB101.ericsson.se> <01OMOOFANQW400008S@mauve.mrochek.com> <918C98C9EE8A0C489EB362DC13E0D60301B0E2@eusaamb101.ericsson.se> To: Eric Turcotte X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora6.dc.icann.org [192.0.46.72]); Mon, 19 Nov 2012 17:08:47 +0000 (UTC) Cc: Ned Freed , "media-types@iana.org" Subject: Re: [media-types] MIME Type registration X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 17:08:52 -0000 > Dear Ned, > Thanks for your comments. Please see my reply below [et nov 19]. > BR, > Eric. Specific responses inline, but your changes address my concerns. I'll also note that since this is a standards tree type you'll need to submit it using whatever process 3GPP has for such things. Ned > -----Original Message----- > From: Ned Freed [mailto:ned.freed@mrochek.com] > Sent: November-16-12 12:01 PM > To: Eric Turcotte > Cc: media-types@iana.org > Subject: Re: [media-types] MIME Type registration > A couple of comments... > > Hi, > > I would like to register (in the standards tree) a new MIME type that has been defined in 3GPP working group SA4. The 3GPP specification where this is defined is: > > http://www.3gpp.org/ftp/Specs/archive/26_series/26.346/26346-980.zip. > > In that sepecification, section C.14 has the MIME type registration information, and is extracted bellow for your consideration/review. > > Please let me know if additional information or questions you may have. > > Thank you, > > Eric Turcotte > > C.14 Registration of MIME type "application/mbms-schedule+xml" > > The MIME-Type registration for "application/mbms-schedule+xml" identifies XML documents that follows the schema " urn:3gpp:metadata:2011:MBMS:scheduleDescription " defined in clause 11.2A.2. > > Type name: application > > Subtype name: mbms-schedule+xml > > Required parameters: > > None > > Optional parameters: > > charset: As specified in RFC 3023 [83] for media type application/xml. > > Encoding considerations: > > This is an XML document and the encoding considerations are the same > > as for media type "application/xml" defined in RFC 3023 [83]. > It's fine to add this, but you still need to specify the encoding. If the type is limited to utf-8 and similar charsets 8bit is appropriate, if > utf-16 variants are allowed it needs to be binary. > ========= > [et nov 19] The encoding is limited to UTF-8 so it should be 8bit as you mention. > ========== Then I would suggest something like: Encoding considerations: 8bit The content of this media type is always utf-8. > > Security considerations: > > The information present in this media format is used to configure the > > receiving application. Thus the usage of the fomat is vulnerable to > > attacks modifying or spoofing the content of this format. It is > > recommended to use source authentication and integrity protection. > You should also comment on any need, or the lack of any need, for privacy protection. That is, does this configuration information contain passwords or keys similar things? > ========= > [et nov 19] No there is no need for privacy protection, as the configuration information does not contain passwords or keys or similar. > Would you be OK with the following text (adding 1 sentence at the end? > The information present in this media format is used to configure the receiving > application. Thus the usage of the fomat is vulnerable to attacks modifying or > spoofing the content of this format. It is recommended to use source > authentication and integrity protection. The information carried in the media > format does not contain any private information such as passwords or keys. Sounds good to me! > ========= > > Interoperability considerations: > > None > > Published specification: > > 3GPP TS 26.346 > > Applications which use this media type: > > 3GPP MBMS based applications > > Additional information: > > Magic number(s): None > > File extension(s): > > Macintosh file type code(s): > > Person & email address to contact for further information: > > Eric Turcotte (Eric.Turcotte@ericsson.com) 3GPP TSG SA WG4 > > Intended usage: COMMON > > Restrictions on usage: > > None > > Author: > > 3GPP TSG SA WG4 > > Change controller: > > 3GPP TSG SA WG4 > Ned > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types From duerst@it.aoyama.ac.jp Mon Nov 19 17:41:54 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D980621F87A4 for ; Mon, 19 Nov 2012 17:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.59 X-Spam-Level: X-Spam-Status: No, score=-100.59 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 ydlHYOVGvvyE for ; Mon, 19 Nov 2012 17:41:54 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 728A021F8794 for ; Mon, 19 Nov 2012 17:41:46 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id qAK1fXHj020638 for ; Tue, 20 Nov 2012 10:41:35 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 36e7_3a18_6a0c4188_32b3_11e2_9f9c_001d096c566a; Tue, 20 Nov 2012 10:41:32 +0900 Received: from [IPv6:::1] ([133.2.210.1]:38818) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 20 Nov 2012 10:41:34 +0900 Message-ID: <50AADFCB.2090903@it.aoyama.ac.jp> Date: Tue, 20 Nov 2012 10:41:31 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Enrico Marocco References: <508E964B.5060006@telecomitalia.it> <50924C0F.9050308@it.aoyama.ac.jp> <50AA547D.2020002@telecomitalia.it> In-Reply-To: <50AA547D.2020002@telecomitalia.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "media-types@ietf.org" , "draft-ietf-alto-protocol@tools.ietf.org" , Martin Stiemerling Subject: Re: [media-types] Media type review for draft-ietf-alto-protocol-13 X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 01:41:55 -0000 Hello Enrico, On 2012/11/20 0:47, Enrico Marocco wrote: > Martin, all, > > apologies for an overly vague request, and for a response time closer to > deep space rather than human communications. IETF meeting and day job > took the upper hand, my bad. Let me try again. > > The ALTO protocol has been specified in the ALTO WG, initially in APP > and later in TSV. The main design choices had been made with the > contribution of several APPs experts (Peter S-A is officially the > technical advisor of the group), but their supervision has weakened with > time. It would thus be very useful to have a review of the key parts, > including the media type registration part, now that the WG considers > the draft ready, but before submitting it to the IESG. > > The document is draft-ietf-alto-protocol-13. It is available at > http://tools.ietf.org/html/draft-ietf-alto-protocol-13 > > The registration request, for 10 "application/alto-*+json" media types, > is in section 9.1: > http://tools.ietf.org/html/draft-ietf-alto-protocol-13#section-9.1 > > If anyone on this list could spend a few minutes even only for a sanity > check, that would be very useful and extremely appreciated. There are quite some people who are ready to do this, but as I have explained in my previous mail, the number of people increases *significantly* if you actually copy-paste the template, not just a pointer. Many thanks in advance for doing so. Regards, Martin. > Enrico > > On 11/1/12 11:16 AM, "Martin J. Dürst" wrote: >> Hello Enrico, >> >> This is a standing comment of mine: Please send the actual registration >> template to the media-types@ietf.org list, not just a pointer to a draft >> (in your case not even an URI, so it's not directly "actionable"). >> >> This increases the chance of getting relevant comments significantly. >> >> Regards, Martin. >> >> On 2012/10/29 23:44, Enrico Marocco wrote: >>> Hi, >>> >>> as document shepherd, I would kindly request a review on the media type >>> registration part of draft-ietf-alto-protocol-13 that is about to be >>> submitted to the IESG for publication. >>> >>> Thank you in advance! >>> >>> Enrico >>> >>> >>> >>> >>> _______________________________________________ >>> media-types mailing list >>> media-types@ietf.org >>> https://www.ietf.org/mailman/listinfo/media-types > > > > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types From enrico.marocco@telecomitalia.it Tue Nov 20 00:25:43 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B21021F85B1 for ; Tue, 20 Nov 2012 00:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.269 X-Spam-Level: X-Spam-Status: No, score=-101.269 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 ZMAo2U-juSWd for ; Tue, 20 Nov 2012 00:25:42 -0800 (PST) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id 1CED521F85A1 for ; Tue, 20 Nov 2012 00:25:42 -0800 (PST) Received: from grfhub702rm001.griffon.local (10.19.3.9) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.3.279.5; Tue, 20 Nov 2012 09:25:40 +0100 Received: from MacLab.local (10.229.8.21) by smtp.telecomitalia.it (10.19.9.235) with Microsoft SMTP Server (TLS) id 8.3.279.5; Tue, 20 Nov 2012 09:25:40 +0100 Message-ID: <50AB3E83.7000008@telecomitalia.it> Date: Tue, 20 Nov 2012 09:25:39 +0100 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <508E964B.5060006@telecomitalia.it> <50924C0F.9050308@it.aoyama.ac.jp> <50AA547D.2020002@telecomitalia.it> <50AADFCB.2090903@it.aoyama.ac.jp> In-Reply-To: <50AADFCB.2090903@it.aoyama.ac.jp> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080304070207060701010908" X-TI-Disclaimer: Disclaimer1 Cc: "media-types@ietf.org" , "draft-ietf-alto-protocol@tools.ietf.org" , Martin Stiemerling Subject: Re: [media-types] Media type review for draft-ietf-alto-protocol-13 X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 08:25:43 -0000 --------------ms080304070207060701010908 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/20/12 2:41 AM, "Martin J. D=FCrst" wrote: >> The document is draft-ietf-alto-protocol-13. It is available at >> http://tools.ietf.org/html/draft-ietf-alto-protocol-13 >> >> The registration request, for 10 "application/alto-*+json" media types= , >> is in section 9.1: >> http://tools.ietf.org/html/draft-ietf-alto-protocol-13#section-9.1 >> >> If anyone on this list could spend a few minutes even only for a sanit= y >> check, that would be very useful and extremely appreciated. >=20 > There are quite some people who are ready to do this, but as I have=20 > explained in my previous mail, the number of people increases=20 > *significantly* if you actually copy-paste the template, not just a=20 > pointer. Many thanks in advance for doing so. It is actually one template for 10 registrations, with pointers to the relevant sections. It's probably more easily accessible from html, but nonetheless, a cut&paste is very easy :-) Here it is: This document requests the registration of multiple media types, listed in Table 2. +-------------+------------------------------+-----------------+ | Type | Subtype | Specification | +-------------+------------------------------+-----------------+ | application | alto-directory+json | Section 6.7 | | application | alto-networkmap+json | Section 6.8.1.1 | | application | alto-networkmapfilter+json | Section 6.8.2.1 | | application | alto-costmap+json | Section 6.8.1.2 | | application | alto-costmapfilter+json | Section 6.8.2.2 | | application | alto-endpointprop+json | Section 6.8.3.1 | | application | alto-endpointpropparams+json | Section 6.8.3.1 | | application | alto-endpointcost+json | Section 6.8.4.1 | | application | alto-endpointcostparams+json | Section 6.8.4.1 | | application | alto-error+json | Section 6.5 | +-------------+------------------------------+-----------------+ Type name: application Subtype name: This documents requests the registration of multiple subtypes, as listed in Table 2. Required parameters: n/a Optional parameters: n/a Encoding considerations: Encoding considerations are identical to those specified for the 'application/json' media type. See [RFC4627]. Security considerations: Security considerations relating to the generation and consumption of ALTO protocol messages are discussed in Section 10. Interoperability considerations: This document specifies format of conforming messages and the interpretation thereof. Published specification: This document is the specification for these media types; see Table 2 for the section documenting each media type. Applications that use this media type: ALTO Servers and ALTO Clients either standalone or embedded within other applications. Additional information: Magic number(s): n/a File extension(s): This document uses the mime type to refer to protocol messages and thus does not require a file extension. Macintosh file type code(s): n/a Person & email address to contact for further information: See "Authors' Addresses" section. Intended usage: COMMON Restrictions on usage: n/a Author: See "Authors' Addresses" section. Change controller: Internet Engineering Task Force (mailto:iesg@ietf.org). Enrico --------------ms080304070207060701010908 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/ 5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0 UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2 aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6 R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjExMjAw ODI1MzlaMCMGCSqGSIb3DQEJBDEWBBQftaFBI861S59E1SHPZn1O8g0UgzBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEANgDW2bJHYo8WvJj4ayNvMphoO6q00eZ/xSjUJraf xof1ecnBhmwtOj2DJRWTBVvy3+qo69AR6jn5ufPugG+k7rvDqBm2uk/XR+9SnSgIF9bCjO7Q sGNK2vL419CYLqzYOB38DhvbJypF9R9y6e82+j2Gy2gNY1FXwVDy3wGfTiDKBkiWztqoVKeH VuSQA2UiBHhVvigxC40kOoKTPKyyrkGBzxlppLlHuYXETEqWXYIQIsPBRAq4rLsLpzdGzADx VxjUgTWDcaGoVEUA+609Ry7FaGywIKkAOc6g3Wh1oUpp8dMBgJknO6pQxYcTtpXFuc/fj3W+ p7xEgk50hUJiyQAAAAAAAA== --------------ms080304070207060701010908-- From eric.turcotte@ericsson.com Tue Nov 20 08:21:37 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0393621F870C for ; Tue, 20 Nov 2012 08:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.445 X-Spam-Level: X-Spam-Status: No, score=-4.445 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-4] 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 C+BiUmoC+k81 for ; Tue, 20 Nov 2012 08:21:36 -0800 (PST) Received: from pechora3.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7C221F8695 for ; Tue, 20 Nov 2012 08:21:35 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id qAKGLEcU003410 for ; Tue, 20 Nov 2012 16:21:34 GMT Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qAKGS6of004349; Tue, 20 Nov 2012 10:28:20 -0600 Received: from EUSAAHC004.ericsson.se (147.117.188.84) by eusaamw0706.eamcs.ericsson.se (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 11:20:55 -0500 Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.001; Tue, 20 Nov 2012 11:20:55 -0500 From: Eric Turcotte To: Ned Freed Thread-Topic: [media-types] MIME Type registration Thread-Index: AQHNxniGDelSV0BP0EmGw35BLt5fiJfy5h6Q Date: Tue, 20 Nov 2012 16:20:54 +0000 Message-ID: <918C98C9EE8A0C489EB362DC13E0D60301C4E3@eusaamb101.ericsson.se> References: <918C98C9EE8A0C489EB362DC13E0D6030161D8@EUSAAMB101.ericsson.se> <01OMOOFANQW400008S@mauve.mrochek.com> <918C98C9EE8A0C489EB362DC13E0D60301B0E2@eusaamb101.ericsson.se> <01OMSV9ZXS4800008S@mauve.mrochek.com> In-Reply-To: <01OMSV9ZXS4800008S@mauve.mrochek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Tue, 20 Nov 2012 16:21:34 +0000 (UTC) Cc: "media-types@iana.org" Subject: Re: [media-types] MIME Type registration X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 16:21:37 -0000 Hi Ned, As a results of your comments, it seems there may be updates needed in the = 3GPP sepcifications, and I can work/submit those at next 3GPP SA4 meeting (= end of Jan 2013). Only Annex C.14 would be modified for the following 2 asp= ects: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1- with respect to encoding Encoding considerations 8bit. This is an XML document and the encoding considerations are the same as = for media type "application/xml" defined in RFC 3023 [83]. 2- with respect to security Security considerations: The information present in this media format is used to configure the re= ceiving application. Thus the usage of the fomat is vulnerable to attacks= modifying or spoofing the content of this format. It is recommended to use= source authentication and integrity protection. The=20 information carried in the media format does not contain any private inform= ation such as passwords or keys. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I will wait a bit to see if there are other comments, befor proceeding to n= ext steps with this. Thanks, Eric. -----Original Message----- From: Ned Freed [mailto:ned.freed@mrochek.com]=20 Sent: November-19-12 11:59 AM To: Eric Turcotte Cc: Ned Freed; media-types@iana.org Subject: Re: [media-types] MIME Type registration > Dear Ned, > Thanks for your comments. Please see my reply below [et nov 19]. > BR, > Eric. Specific responses inline, but your changes address my concerns. I'll also = note that since this is a standards tree type you'll need to submit it usin= g whatever process 3GPP has for such things. Ned > -----Original Message----- > From: Ned Freed [mailto:ned.freed@mrochek.com] > Sent: November-16-12 12:01 PM > To: Eric Turcotte > Cc: media-types@iana.org > Subject: Re: [media-types] MIME Type registration =20 > A couple of comments... > > Hi, > > I would like to register (in the standards tree) a new MIME type that h= as been defined in 3GPP working group SA4. The 3GPP specification where thi= s is defined is: > > http://www.3gpp.org/ftp/Specs/archive/26_series/26.346/26346-980.zip. > > In that sepecification, section C.14 has the MIME type registration inf= ormation, and is extracted bellow for your consideration/review. > > Please let me know if additional information or questions you may have. > > Thank you, > > Eric Turcotte > > C.14 Registration of MIME type "application/mbms-schedule+xml" > > The MIME-Type registration for "application/mbms-schedule+xml" identifi= es XML documents that follows the schema " urn:3gpp:metadata:2011:MBMS:sche= duleDescription " defined in clause 11.2A.2. > > Type name: application > > Subtype name: mbms-schedule+xml > > Required parameters: > > None > > Optional parameters: > > charset: As specified in RFC 3023 [83] for media type application/xml. > > Encoding considerations: > > This is an XML document and the encoding considerations are the same=20 > > as for media type "application/xml" defined in RFC 3023 [83]. > It's fine to add this, but you still need to specify the encoding. If=20 > the type is limited to utf-8 and similar charsets 8bit is appropriate,=20 > if > utf-16 variants are allowed it needs to be binary. > =3D=3D=3D=3D=3D=3D=3D=3D=3D > [et nov 19] The encoding is limited to UTF-8 so it should be 8bit as you = mention. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Then I would suggest something like: Encoding considerations: 8bit The content of this media type is always utf-8. > > Security considerations: > > The information present in this media format is used to configure=20 > > the receiving application. Thus the usage of the fomat is vulnerable=20 > > to attacks modifying or spoofing the content of this format. It is=20 > > recommended to use source authentication and integrity protection. > You should also comment on any need, or the lack of any need, for privacy= protection. That is, does this configuration information contain passwords= or keys similar things? > =3D=3D=3D=3D=3D=3D=3D=3D=3D > [et nov 19] No there is no need for privacy protection, as the configurat= ion information does not contain passwords or keys or similar. > Would you be OK with the following text (adding 1 sentence at the end? > The information present in this media format is used to configure the=20 > receiving application. Thus the usage of the fomat is vulnerable to=20 > attacks modifying or spoofing the content of this format. It is=20 > recommended to use source authentication and integrity protection. The=20 > information carried in the media format does not contain any private info= rmation such as passwords or keys. Sounds good to me! > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > Interoperability considerations: > > None > > Published specification: > > 3GPP TS 26.346 > > Applications which use this media type: > > 3GPP MBMS based applications > > Additional information: > > Magic number(s): None > > File extension(s): > > Macintosh file type code(s): > > Person & email address to contact for further information: > > Eric Turcotte (Eric.Turcotte@ericsson.com) 3GPP TSG SA WG4 > > Intended usage: COMMON > > Restrictions on usage: > > None > > Author: > > 3GPP TSG SA WG4 > > Change controller: > > 3GPP TSG SA WG4 > Ned > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types From l.moreau@ecs.soton.ac.uk Tue Nov 20 08:25:16 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDB521F848B for ; Tue, 20 Nov 2012 08:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 bbkmNV0Ba50g for ; Tue, 20 Nov 2012 08:25:15 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 0C30C21F8485 for ; Tue, 20 Nov 2012 08:25:14 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id qAKGONLj011382; Tue, 20 Nov 2012 16:24:23 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk qAKGONLj011382 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1353428665; bh=pjBscihJnvAm8PRb0Id8ZC+l1gA=; h=Date:From:MIME-Version:To:CC:Subject:References:In-Reply-To; b=UHv6zdXjY3vfMsK4pJrfR5XbDULwkRkzeo43UBjcDyduypaa3A5ZxK95M9iagn1pz qxPVcOJPd4W/1/AJAcIbhf74JO7jSkWJZk8/wbX7J8GZANlhiRbDyQ99oG3CWF0LWb YpGi4giXoshwyMbOcL+L/Z5G/f1fQtDAG/pD1pO8= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id oAJGON0430657544fw ret-id none; Tue, 20 Nov 2012 16:24:25 +0000 Received: from smurf.ecs.soton.ac.uk ([IPv6:2001:630:d0:f111:222:4dff:fe6b:45ed]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id qAKGOK3h018495; Tue, 20 Nov 2012 16:24:20 GMT Message-ID: Date: Tue, 20 Nov 2012 16:24:20 +0000 From: Luc Moreau User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: Bjoern Hoehrmann , media-types@ietf.org, duerst@it.aoyama.ac.jp References: <50126B46.8030004@ecs.soton.ac.uk> <50AB763D.4040509@ecs.soton.ac.uk> <50ABAEB4.4080107@ecs.soton.ac.uk> In-Reply-To: <50AB763D.4040509@ecs.soton.ac.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=oAJGON043065754400; tid=oAJGON0430657544fw; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: qAKGONLj011382 X-ECS-MailScanner-From: l.moreau@ecs.soton.ac.uk Cc: "team-prov-chairs@w3.org" , public-prov-comments@w3.org Subject: Re: [media-types] [ietf-types] Mime Type registration (PROV Last Call) X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 16:25:16 -0000 Dear all Thanks for your feedback. We have updated the registration request for media type "text/provenance-notation" as follows. Your comments would be appreciated, Kind regards, Luc ----------------------- The media type of PROV-N is text/provenance-notation. The content encoding of PROV-N content is UTF-8. Contact: Ivan Herman See also: How to Register a Media Type for a W3C Specification Internet Media Type registration, consistency of use TAG Finding 3 June 2002 (Revised 4 September 2002) The Internet Media Type / MIME Type for PROV-N is "text/provenance-notation". It is recommended that PROV-N files have the extension ".provn" (all lowercase) on all platforms. It is recommended that PROV-N files stored on Macintosh HFS file systems be given a file type of "TEXT". The information that follows has been submitted to the IESG for review, approval, and registration with IANA. Type name: text Subtype name: provenance-notation Required parameters: charset — the value of charset must always be UTF-8. Optional parameters: None Encoding considerations: 8bit The syntax of PROV-N is expressed over code points in Unicode [UNICODE]. The encoding is always UTF-8 [UTF-8]. Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F] Security considerations: PROV-N is a general-purpose language for describing the provenance of things; applications may evaluate given data to infer more descriptions or to dereference URIs, invoking the security considerations of the scheme for that URI. Note in particular, the privacy issues in [RFC3023] section 10 for HTTP URIs. Data obtained from an inaccurate or malicious data source may lead to inaccurate or misleading conclusions, as well as the dereferencing of unintended URIs. Care must be taken to align the trust in consulted resources with the sensitivity of the intended use of the data. PROV-N is used to express the provenance of arbitrary application data; security considerations will vary by domain of use. Security tools and protocols applicable to text (e.g. PGP encryption, MD5 sum validation, password-protected compression) may also be used on PROV-N documents. Security/privacy protocols must be imposed which reflect the sensitivity of the embedded information. PROV-N can express data which is presented to the user, for example, by means of label attributes. Application rendering strings retrieved from untrusted PROV-N documents must ensure that malignant strings may not be used to mislead the reader. The security considerations in the media type registration for XML ([RFC3023] section 10) provide additional guidance around the expression of arbitrary data and markup. PROV-N is a language for describing the provenance of things, and therefore a PROV-N document is metadata for other resources. Untrusted PROV-N documents may mislead its consumers by indicating that a third-party resource has a reputable lineage, when it has not. Provenance of PROV-N document should be sought. PROV-N uses qualified names mappeable to IRIs as term identifiers. Applications interpreting data expressed in PROV-N should address the security issues of Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8, as well as Uniform Resource Identifier (URI): Generic Syntax [RFC3986] Section 7. Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "о" may appear similar to a Latin "o"). A character followed by combining characters may have the same visual representation as another character (LATIN SMALL LETTER E followed by COMBINING ACUTE ACCENT has the same visual representation as LATIN SMALL LETTER E WITH ACUTE). Any person or application that is writing or interpreting data in PROV-N must take care to use the IRI that matches the intended semantics, and avoid IRIs that make look similar. Further information about matching of similar characters can be found in Unicode Security Considerations [UNISEC] and Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8. Interoperability considerations: There are no known interoperability issues. Published specification: PROV-N: The Provenance Notation, Moreau, Missier, eds., Cheney, Soiland-Reyes http://www.w3.org/TR/prov-n/, 2012. Applications which use this media type: It may be used by any application for publishing provenance information. This format is designed to be a human-readable form of provenance. Additional information: Magic number(s): PROV-N documents may have the strings 'document' near the beginning of the document. File extension(s): ".provn" Base URI: There are no constructs in the PROV-N Syntax to change the Base IRI. Macintosh file type code(s): "TEXT" Person & email address to contact for further information: Ivan Herman, ivan@w3.org Intended usage: COMMON Restrictions on usage: None Author/Change controller: The PROV-N specification is the product of the World Wide Web Consortium's PROV Working Group. The W3C has change control over this specification. On 07/27/2012 01:41 PM, Bjoern Hoehrmann wrote: > * Luc Moreau wrote: >> Type name: >> text >> >> Subtype name: >> provenance-notation >> >> Required parameters: >> None >> >> Optional parameters: >> charset — this parameter is mandatory. The value of charset is always UTF-8. > This seems to need work, it's not optional if it is mandatory, is it. > And The second sentence is a statement of fact that is easily contr- > dicted by content. > >> Encoding considerations: >> The syntax of PROV-N is expressed over code points in Unicode >> [UNICODE5]. The encoding is always UTF-8 [UTF-8]. >> Unicode code points may also be expressed using an \uXXXX (U+0 to >> U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a >> hexadecimal digit [0-9A-F] > This field should contain one of the values in RFC 4288 or its successor > if that has been approved already, like "binary". > >> Applications which use this media type: >> No widely deployed applications are known to use this media type. It may >> be used by some web services and clients consuming their data. > You can remove the first sentence, this is to give people an idea > whether this is for Word processing applications or cryptographic > key exchange systems or whatever. > >> Person & email address to contact for further information: >> public-prov-comments@w3.org > This does not qualify as "Person & email address". -- Professor Luc Moreau Electronics and Computer Science tel: +44 23 8059 4487 University of Southampton fax: +44 23 8059 2865 Southampton SO17 1BJ email: l.moreau@ecs.soton.ac.uk United Kingdom http://www.ecs.soton.ac.uk/~lavm From abegen@cisco.com Tue Nov 20 08:21:45 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A645721F875B for ; Tue, 20 Nov 2012 08:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 TgTqLzGM26gt for ; Tue, 20 Nov 2012 08:21:45 -0800 (PST) Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:201::1:72]) by ietfa.amsl.com (Postfix) with ESMTP id E203F21F876F for ; Tue, 20 Nov 2012 08:21:44 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by pechora2.lax.icann.org (8.13.8/8.13.8) with ESMTP id qAKGLOot032581 for ; Tue, 20 Nov 2012 16:21:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=272; q=dns/txt; s=iport; t=1353428504; x=1354638104; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=zbWl8c09flSXEr7OhB5MUc5uiJCNvUEZ/yvo4n5n978=; b=WwUzpYngYR0ys67Y9gelEGoLnkF9/dm/rlQoy9ceMpsewLhhNp/1NUi8 CZsD4rD25IlGEHle+DGUE4oc9jXAjI6pAzPUMwFFNsq4E+H2mjV30EUrX 01N1E3RYdREjtmpp5zVObncDqi4g9Yxssr9EBbFp6OJGrfvWLb9QyNSPx E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEKANGsq1CtJV2b/2dsb2JhbABFgmyCbb0AFmwHgiABBDo/EgEqFEInBA4NiAUBCrARkEcEkElhA6Y/gm+CGQ X-IronPort-AV: E=McAfee;i="5400,1158,6901"; a="144463178" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 20 Nov 2012 16:20:23 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAKGKNIh024682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Nov 2012 16:20:23 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Tue, 20 Nov 2012 10:20:23 -0600 From: "Ali C. Begen (abegen)" To: "ietf-types@iana.org" Thread-Topic: Registration of VP8 media subtype Thread-Index: AQHNxzrxEdBT649K002GmpMSNwN/Dw== Date: Tue, 20 Nov 2012 16:20:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.242.36] Content-Type: text/plain; charset="us-ascii" Content-ID: <69B072B2756E334189B58E700B6B46E1@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora2.lax.icann.org [192.0.33.72]); Tue, 20 Nov 2012 16:21:44 +0000 (UTC) X-Mailman-Approved-At: Thu, 22 Nov 2012 11:03:21 -0800 Cc: "draft-ietf-payload-vp8@tools.ietf.org" , "payload-chairs@tools.ietf.org" Subject: [media-types] Registration of VP8 media subtype X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 16:21:45 -0000 Hello, The VP8 draft is currently in WGLC in the Payload WG. https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_text=3D1 The media type registration is in section 6.1. Comments on the registration are welcome. -acbegen Payload WG Co-Chair From duerst@it.aoyama.ac.jp Tue Nov 27 01:40:27 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8467D21F857A for ; Tue, 27 Nov 2012 01:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.284 X-Spam-Level: X-Spam-Status: No, score=-97.284 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 66C-axt+VcE9 for ; Tue, 27 Nov 2012 01:40:27 -0800 (PST) Received: from pechora8.dc.icann.org (unknown [IPv6:2620:0:2830:201::1:74]) by ietfa.amsl.com (Postfix) with ESMTP id AD1E221F856B for ; Tue, 27 Nov 2012 01:40:26 -0800 (PST) Received: from acspool01.acbb.aoyama.ac.jp (acspool01.acbb.aoyama.ac.jp [133.2.20.162]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id qAR9e2X8030276 for ; Tue, 27 Nov 2012 09:40:23 GMT Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by acspool01.acbb.aoyama.ac.jp (secret/secret) with ESMTP id qAR98eDN011434 for ; Tue, 27 Nov 2012 18:08:40 +0900 Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id qAR95MVN023657 for ; Tue, 27 Nov 2012 18:05:22 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 224d_96c9_931c28e0_3871_11e2_9ac5_001d096c5782; Tue, 27 Nov 2012 18:05:22 +0900 Received: from [IPv6:::1] ([133.2.210.1]:57722) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 27 Nov 2012 18:05:22 +0900 Message-ID: <50B4824E.2060109@it.aoyama.ac.jp> Date: Tue, 27 Nov 2012 18:05:18 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Delayed for 00:31:19 by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Tue, 27 Nov 2012 09:40:24 +0000 (UTC) X-Mailman-Approved-At: Tue, 27 Nov 2012 07:26:46 -0800 Cc: "ietf-types@iana.org" , "draft-ietf-payload-vp8@tools.ietf.org" , "payload-chairs@tools.ietf.org" Subject: Re: [media-types] Registration of VP8 media subtype X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 09:40:27 -0000 Hello Ali, This is a standing comment of mine: Please send the actual registration template to the media-types@ietf.org list, not just a pointer to a draft (in your case not even an URI, so it's not directly "actionable"). This increases the chance of getting relevant comments significantly. Thanks and regards, Martin. On 2012/11/21 1:20, Ali C. Begen (abegen) wrote: > Hello, > > The VP8 draft is currently in WGLC in the Payload WG. > https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_text=1 > > > The media type registration is in section 6.1. > > Comments on the registration are welcome. > > > -acbegen > Payload WG Co-Chair > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types > From abegen@cisco.com Tue Nov 27 07:46:35 2012 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2737821F8471 for ; Tue, 27 Nov 2012 07:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 KBynfgugR3Wr for ; Tue, 27 Nov 2012 07:46:34 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 36F2021F8235 for ; Tue, 27 Nov 2012 07:46:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2233; q=dns/txt; s=iport; t=1354031194; x=1355240794; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=2Jw+hPSGu/a45Ni3M0Ki2DjYVARwpxTMs3soWMtBo7w=; b=WwG86UtoIkF7ccPKQy7eYbtSNFGIkWI0TBQfyiWycjTxTkYuMvbUUAx3 Vzb/q7qj4cdd60nv74KwJBdBIvQVJVtWTZVXYy4K4JDAhk6H6y3iVxlOQ cHiKo8jpl1IiJo8D4JRZds8RRcvrSny68oRHUCq+hVb2+ZkOP7LwkH0Ku 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoLAJ3ftFCtJV2d/2dsb2JhbABEgmy9MoECB4IgAQQ6PxIBKhQxEScECgQFCIdzAw8BC7A+hm4NiVAEi1F0g1VhA4dbjFGNCYUQgnCBazU X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="146682747" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 27 Nov 2012 15:46:33 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qARFkXSf032140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 15:46:33 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 09:46:33 -0600 From: "Ali C. Begen (abegen)" To: "media-types@ietf.org" Thread-Topic: Registration of VP8 media subtype Thread-Index: AQHNzLZfLfIuqWuCnkOF9SqqdhGFiw== Date: Tue, 27 Nov 2012 15:46:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.244.191] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 27 Nov 2012 07:54:42 -0800 Cc: "draft-ietf-payload-vp8@tools.ietf.org" , "payload-chairs@tools.ietf.org" Subject: [media-types] Registration of VP8 media subtype X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: