Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAB621F8ABD for ; Mon, 26 Dec 2011 00:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.467 X-Spam-Level: X-Spam-Status: No, score=-106.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB18=0.131, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqAtb+WCd+3o for ; Mon, 26 Dec 2011 00:09:03 -0800 (PST) Received: from pechora1.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id E728621F8ABB for ; Mon, 26 Dec 2011 00:09:02 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id pBQ88f2L015594 for ; Mon, 26 Dec 2011 00:09:02 -0800 Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWS00AN6W503E@szxga05-in.huawei.com> for ietf-types@iana.org; Mon, 26 Dec 2011 15:43:48 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWS003QLW4OQI@szxga05-in.huawei.com> for ietf-types@iana.org; Mon, 26 Dec 2011 15:43:48 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGA30390; Mon, 26 Dec 2011 15:43:47 +0800 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 26 Dec 2011 15:43:46 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.136]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Mon, 26 Dec 2011 15:43:45 +0800 Date: Mon, 26 Dec 2011 07:43:44 +0000 From: Roni even X-Originating-IP: [172.24.1.70] To: "ietf-types@iana.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_+5GtDk5n2qAP/ytvKf850A)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: registeration of audio EVRCNW, EVRCNW0 and EVRCNW1 media subtype Thread-index: AQHMw6IYFHGBhQEdbUK2ukl7vCSsKg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected X-Greylist: Delayed for 00:24:24 by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Mon, 26 Dec 2011 08:09:02 +0000 (UTC) Cc: "payload@ietf.org" Subject: [ietf-types] registeration of audio EVRCNW, EVRCNW0 and EVRCNW1 media subtype X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 08:09:04 -0000 --Boundary_(ID_+5GtDk5n2qAP/ytvKf850A) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, draft-ietf-avt-rtp-evrc-nw-05 has passed Working Group Last Call in the Payload Working Group. The new registrations are in Section 3.1 of the document. http://tools.ietf.org/html/draft-ietf-avt-rtp-evrc-nw-05#section-9.1 The information is also available below. Comments on the registration are welcome. Roni Even Payload co-chair This document introduces a new EVRC-NW 'audio' media subtypes. 9.1. Media Type Registrations Following the guidelines in RFC 4855 [8] and RFC 4288 [9], this section registers new 'audio' media subtypes for EVRC-NW. 9.1.1. Registration of Media Type audio/EVRCNW Type name: audio Subtype names: EVRCNW Required parameters: None Optional parameters: These parameters apply to RTP transfer only. mode-set-recv: A subset of EVRC-NW modes. Possible values are a comma separated list of modes from the set {0,1,2,3,4,5,6,7} (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D). A decoder can use this attribute to inform an encoder of its preference to operate in a specified subset of modes. Absence of this parameter signals the mode set {1,2,3,4,5,6,7}. ptime: see RFC 4566 [10]. maxptime: see RFC 4566. maxinterleave: Maximum number for interleaving length (field LLL in the Interleaving Octet)[0..7]. The interleaving lengths used in the entire session MUST NOT exceed this maximum value. If not signaled, the maxinterleave length MUST be 5. silencesupp: see Section 6.1 in RFC 4788. dtxmax: see Section 6.1 in RFC 4788. dtxmin: see Section 6.1 in RFC 4788. hangover: see Section 6.1 in RFC 4788. Encoding considerations: This media type is framed binary data (see RFC 4288, Section 4.8) and is defined for transfer of EVRC-NW encoded data via RTP using the Interleaved/Bundled packet format specified in RFC 3558 [6]. Security considerations: See Section 15. Interoperability considerations: None Published specification: The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D. The transfer method with the Interleaved/Bundled packet format via RTP is specified in RFC 3558 [6]. See Section 6 for details for EVRC-NW. Applications that use this media type: It is expected that many VoIP applications (as well as mobile applications) will use this type. Additional information: The following applies to stored-file transfer methods: Magic number: #!EVRCNW\n (see Section 8) File extensions: enw, ENW Macintosh file type code: None Object identifier or OID: None EVRC-NW speech frames may also be stored in the file format "3g2" defined in 3GPP2 C.S0050-B, which is identified using the media types "audio/3gpp2" or "video/3gpp2" registered by RFC 4393 [11]. Person & email address to contact for further information: Zheng Fang > Intended usage: COMMON Restrictions on usage: When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be used. In all other contexts, the file format defined in Section 8 SHALL be used. See Section 6 for details for EVRC-NW. Author: Zheng Fang > Change controller: IETF Payload working group delegated from the IESG. 9.1.2. Registration of Media Type audio/EVRCNW0 Type name: audio Subtype names: EVRCNW0 Required parameters: None Optional parameters: These parameters apply to RTP transfer only. mode-set-recv: A subset of EVRC-NW modes. Possible values are a comma separated list of modes from the set {0,1,2,3,4,5,6,7} (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D). A decoder can use this attribute to inform an encoder of its preference to operate in a specified subset of modes. Absence of this parameter signals the mode set {1,2,3,4,5,6,7}. ptime: see RFC 4566. silencesupp: see Section 6.1 in RFC 4788. dtxmax: see Section 6.1 in RFC 4788. dtxmin: see Section 6.1 in RFC 4788. hangover: see Section 6.1 in RFC 4788. Encoding considerations: This media type is framed binary data (see RFC 4288, Section 4.8) and is defined for transfer of EVRC-NW encoded data via RTP using the Header-Free packet format specified in RFC 3558 [6]. Security considerations: See Section 15. Interoperability considertaions: None Published specification: The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D. The transfer method with the Header-Free packet format via RTP is specified in RFC 3558 [6]. Applications that use this media type: It is expected that many VoIP applications (as well as mobile applications) will use this type. Additional information: None Person & email address to contact for further information: Zheng Fang > Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [5], the RTP payload format specified in Section 4.2 of RFC 3558 [6] SHALL be used. This media type SHALL NOT be used for storage or file transfer, instead audio/EVRCNW SHALL be used. Author: Zheng Fang > Change controller: IETF Payload working group delegated from the IESG. 9.1.3. Registration of Media Type audio/EVRCNW1 Type name: audio Subtype names: EVRCNW1 Required parameters: None Optional parameters: These parameters apply to RTP transfer only. mode-set-recv: A subset of EVRC-NW modes. Possible values are a comma separated list of modes from the set {0,1} (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D). A decoder can use this attribute to inform an encoder of its preference to operate in a specified subset of modes. A value of 0 signals the support for wideband fixed rate (full or half rate, depending on the value of 'fixedrate' parameter). A value of 1 signals narroband fixed rate (full or half rate, depending on the value of 'fixedrate' parameter). Absence of this parameter signals the mode 1. ptime: see RFC 4566. maxptime: see RFC 4566. fixedrate: Indicates the EVRC-NW rate of the session while in single rate operation. Valid values include: 0.5 and 1, where a value of 0.5 indicates the 1/2 rate while a value of 1 indicates the full rate. If this parameter is not present, 1/2 rate is assumed. silencesupp: see Section 6.1 in RFC 4788. dtxmax: see Section 6.1 in RFC 4788. dtxmin: see Section 6.1 in RFC 4788. hangover: see Section 6.1 in RFC 4788. Encoding considerations: This media type is framed binary data (see RFC 4288, Section 4.8) and is defined for transfer of EVRC-NW encoded data via RTP using the Compact Bundled packet format specified in RFC 4788. Security considerations: See Section 15 Interoperability considertaions: None Published specification: The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D. The transfer method with the Compact Bundled packet format via RTP is specified in RFC 4788. Applications that use this media type: It is expected that many VoIP applications (as well as mobile applications) will use this type. Additional information: None Person & email address to contact for further information: Zheng Fang > Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [5], the RTP payload format specified in Section 4 of RFC 4788 SHALL be used. This media type SHALL NOT be used for storage or file transfer, instead audio/EVRCNW SHALL be used. Author: Zheng Fang > Change controller: IETF Payload working group delegated from the IESG. --Boundary_(ID_+5GtDk5n2qAP/ytvKf850A) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT

Hi,

 

draft-ietf-avt-rtp-evrc-nw-05 has passed Working Group Last Call in the Payload Working Group.

 

 

The new registrations are in Section 3.1 of the document. http://tools.ietf.org/html/draft-ietf-avt-rtp-evrc-nw-05#section-9.1

 

The information is also available below.

 

 

 

Comments on the registration are welcome.

 

Roni Even

Payload co-chair

 

 

This document introduces a new EVRC-NW 'audio' media subtypes.

 

9.1.  Media Type Registrations

   Following the guidelines in RFC 4855 [8] and RFC 4288 [9], this
   section registers new 'audio' media subtypes for EVRC-NW.

 

9.1.1.  Registration of Media Type audio/EVRCNW

   Type name: audio

   Subtype names: EVRCNW

   Required parameters: None

   Optional parameters:

   These parameters apply to RTP transfer only.

   mode-set-recv: A subset of EVRC-NW modes.  Possible values are a
   comma separated list of modes from the set {0,1,2,3,4,5,6,7} (see
   Table 2.6.1.2-4 in 3GPP2 C.S0014-D).  A decoder can use this
   attribute to inform an encoder of its preference to operate in a
   specified subset of modes.  Absence of this parameter signals the
   mode set {1,2,3,4,5,6,7}.

   ptime: see RFC 4566 [10].

   maxptime: see RFC 4566.

   maxinterleave: Maximum number for interleaving length (field LLL in
   the Interleaving Octet)[0..7].  The interleaving lengths used in the
   entire session MUST NOT exceed this maximum value.  If not signaled,
   the maxinterleave length MUST be 5.

   silencesupp: see Section 6.1 in RFC 4788.

   dtxmax: see Section 6.1 in RFC 4788.

   dtxmin: see Section 6.1 in RFC 4788.

   hangover: see Section 6.1 in RFC 4788.

   Encoding considerations:

   This media type is framed binary data (see RFC 4288, Section 4.8) and

   is defined for transfer of EVRC-NW encoded data via RTP using the
   Interleaved/Bundled packet format specified in RFC 3558 [6].

   Security considerations: See Section 15.

   Interoperability considerations: None

   Published specification:

   The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D.  The transfer
   method with the Interleaved/Bundled packet format via RTP is
   specified in RFC 3558 [6].  See Section 6 for details for EVRC-NW.

   Applications that use this media type:

   It is expected that many VoIP applications (as well as mobile
   applications) will use this type.

   Additional information:

   The following applies to stored-file transfer methods:

   Magic number: #!EVRCNW\n (see Section 8)

   File extensions: enw, ENW

   Macintosh file type code: None

   Object identifier or OID: None

   EVRC-NW speech frames may also be stored in the file format "3g2"
   defined in 3GPP2 C.S0050-B, which is identified using the media types
   "audio/3gpp2" or "video/3gpp2" registered by RFC 4393 [11].

   Person & email address to contact for further information:

   Zheng Fang <zfang@qualcomm.com>

   Intended usage: COMMON

   Restrictions on usage:

   When this media type is used in the context of transfer over RTP, the
   RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be
   used.  In all other contexts, the file format defined in Section 8
   SHALL be used.  See Section 6 for details for EVRC-NW.

   Author:

   Zheng Fang <zfang@qualcomm.com>

   Change controller:

   IETF Payload working group delegated from the IESG.

 

9.1.2.  Registration of Media Type audio/EVRCNW0

   Type name: audio

   Subtype names: EVRCNW0

   Required parameters: None

   Optional parameters:

   These parameters apply to RTP transfer only.

   mode-set-recv: A subset of EVRC-NW modes.  Possible values are a
   comma separated list of modes from the set {0,1,2,3,4,5,6,7} (see
   Table 2.6.1.2-4 in 3GPP2 C.S0014-D).  A decoder can use this
   attribute to inform an encoder of its preference to operate in a
   specified subset of modes.  Absence of this parameter signals the
   mode set {1,2,3,4,5,6,7}.

   ptime: see RFC 4566.

   silencesupp: see Section 6.1 in RFC 4788.

   dtxmax: see Section 6.1 in RFC 4788.

   dtxmin: see Section 6.1 in RFC 4788.

   hangover: see Section 6.1 in RFC 4788.

   Encoding considerations:

   This media type is framed binary data (see RFC 4288, Section 4.8) and
   is defined for transfer of EVRC-NW encoded data via RTP using the
   Header-Free packet format specified in RFC 3558 [6].

   Security considerations: See Section 15.

   Interoperability considertaions: None

   Published specification:

   The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D.  The transfer

   method with the Header-Free packet format via RTP is specified in RFC
   3558 [6].

   Applications that use this media type:

   It is expected that many VoIP applications (as well as mobile
   applications) will use this type.

   Additional information: None

   Person & email address to contact for further information:

   Zheng Fang <zfang@qualcomm.com>

   Intended usage: COMMON

   Restrictions on usage:

   This media type depends on RTP framing, and hence is only defined for
   transfer via RTP [5], the RTP payload format specified in Section 4.2
   of RFC 3558 [6] SHALL be used.  This media type SHALL NOT be used for
   storage or file transfer, instead audio/EVRCNW SHALL be used.

   Author:

   Zheng Fang <zfang@qualcomm.com>

   Change controller:

   IETF Payload working group delegated from the IESG.

 

 

9.1.3.  Registration of Media Type audio/EVRCNW1

   Type name: audio

   Subtype names: EVRCNW1

   Required parameters: None

   Optional parameters:

   These parameters apply to RTP transfer only.

   mode-set-recv: A subset of EVRC-NW modes.  Possible values are a
   comma separated list of modes from the set {0,1} (see Table 2.6.1.2-4
   in 3GPP2 C.S0014-D).  A decoder can use this attribute to inform an
   encoder of its preference to operate in a specified subset of modes.
   A value of 0 signals the support for wideband fixed rate (full or

   half rate, depending on the value of 'fixedrate' parameter).  A value
   of 1 signals narroband fixed rate (full or half rate, depending on
   the value of 'fixedrate' parameter).  Absence of this parameter
   signals the mode 1.

   ptime: see RFC 4566.

   maxptime: see RFC 4566.

   fixedrate: Indicates the EVRC-NW rate of the session while in single
   rate operation.  Valid values include: 0.5 and 1, where a value of
   0.5 indicates the 1/2 rate while a value of 1 indicates the full
   rate.  If this parameter is not present, 1/2 rate is assumed.

   silencesupp: see Section 6.1 in RFC 4788.

   dtxmax: see Section 6.1 in RFC 4788.

   dtxmin: see Section 6.1 in RFC 4788.

   hangover: see Section 6.1 in RFC 4788.

   Encoding considerations:

   This media type is framed binary data (see RFC 4288, Section 4.8) and
   is defined for transfer of EVRC-NW encoded data via RTP using the
   Compact Bundled packet format specified in RFC 4788.

   Security considerations: See Section 15

   Interoperability considertaions: None

   Published specification:

   The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D.  The transfer
   method with the Compact Bundled packet format via RTP is specified in
   RFC 4788.

   Applications that use this media type:

   It is expected that many VoIP applications (as well as mobile
   applications) will use this type.

   Additional information: None

   Person & email address to contact for further information:

   Zheng Fang <zfang@qualcomm.com>

   Intended usage: COMMON

   Restrictions on usage:

   This media type depends on RTP framing, and hence is only defined for
   transfer via RTP [5], the RTP payload format specified in Section 4
   of RFC 4788 SHALL be used.  This media type SHALL NOT be used for
   storage or file transfer, instead audio/EVRCNW SHALL be used.

   Author:

   Zheng Fang <zfang@qualcomm.com>

   Change controller:

   IETF Payload working group delegated from the IESG.

--Boundary_(ID_+5GtDk5n2qAP/ytvKf850A)-- Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEDF21F8B72 for ; Fri, 16 Dec 2011 10:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muiS5e+VenFN for ; Fri, 16 Dec 2011 10:20:23 -0800 (PST) Received: from pechora1.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id 2107721F8B6C for ; Fri, 16 Dec 2011 10:20:21 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pechora1.lax.icann.org (8.13.8/8.13.8) with SMTP id pBGIK0HY007407 for ; Fri, 16 Dec 2011 10:20:21 -0800 Received: (qmail invoked by alias); 16 Dec 2011 17:53:19 -0000 Received: from dslb-094-223-182-030.pools.arcor-ip.net (EHLO HIVE) [94.223.182.30] by mail.gmx.net (mp024) with SMTP; 16 Dec 2011 18:53:19 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19xLD0J+plxILmy+RMXVVCWx15ZbqhlaMJz5er7/P luVlmxRnFywFcI From: Bjoern Hoehrmann To: James Snell Date: Fri, 16 Dec 2011 18:53:20 +0100 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Greylist: Delayed for 00:26:39 by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Fri, 16 Dec 2011 18:20:21 +0000 (UTC) Cc: ietf-types Subject: Re: [ietf-types] application/atomdeleted+xml X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 18:20:25 -0000 * James Snell wrote: >Hello All, Atom Tombstones is an extension to the Atom syndication >format for identifying deleted entries. Part of the spec creates a >media type for tombstone documents. Prior to finalizing the spec, I >would like to request review of the registration. > >http://tools.ietf.org/html/draft-snell-atompub-tombstones-13 > Applications that use this media type: No known applications > currently use this media type. This is supposed to identify the kind of application, like photo editing software or video playback software or something like that. > Intended usage: COMMON > Author/Change controller: IESG Author and Change controller are two fields in the RFC 4288 template and it does not seem like the IESG could claim authorship here. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A395721F8A7E for ; Fri, 16 Dec 2011 09:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.759 X-Spam-Level: X-Spam-Status: No, score=-5.759 tagged_above=-999 required=5 tests=[AWL=-4.760, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9JohTxW2sKX for ; Fri, 16 Dec 2011 09:40:02 -0800 (PST) Received: from pechora3.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id 2A52E21F86A1 for ; Fri, 16 Dec 2011 09:40:02 -0800 (PST) Received: from mail-ey0-f169.google.com (mail-ey0-f169.google.com [209.85.215.169]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id pBGHdfxF030397 for ; Fri, 16 Dec 2011 17:40:01 GMT Received: by eabm6 with SMTP id m6so1788371eab.28 for ; Fri, 16 Dec 2011 09:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=wu/cjbOjPZTHO1ocSclgsssvh4yA5VcOswHETMNdl9s=; b=Nta3wDtXee+/S4vo8YUftAqBvvucsmP5pEOFiaBrJw59pGfi82p2NE4sx/Wb9yP9ir HrFJl/vikF6hK31OQBg6PPrKvtMqKHTLX8TXT3MsvNc78XI9l6LGq16769SiUiv523sD UYTrC1FMHUPLjTqCYAF1UrV5/DZDplD2x4vWo= MIME-Version: 1.0 Received: by 10.204.152.208 with SMTP id h16mr3275942bkw.15.1324057179430; Fri, 16 Dec 2011 09:39:39 -0800 (PST) Received: by 10.205.81.205 with HTTP; Fri, 16 Dec 2011 09:39:39 -0800 (PST) Date: Fri, 16 Dec 2011 09:39:39 -0800 Message-ID: From: James Snell To: ietf-types Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Fri, 16 Dec 2011 17:40:02 +0000 (UTC) Subject: [ietf-types] application/atomdeleted+xml X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 17:40:02 -0000 Hello All, Atom Tombstones is an extension to the Atom syndication format for identifying deleted entries. Part of the spec creates a media type for tombstone documents. Prior to finalizing the spec, I would like to request review of the registration. http://tools.ietf.org/html/draft-snell-atompub-tombstones-13 Type name: application Subtype name: atomdeleted+xml Required parameters: None. Optional parameters: "charset": This parameter has semantics identical to the charset parameter of the "application/xml" media type as specified in [RFC3023]. Encoding considerations: Identical to those of "application/xml" as described in [RFC3023], Section 3.2. Security considerations: As defined in this specification. In addition, as this media type uses the "+xml" convention, it shares the same security considerations as described in [RFC3023], Section 10. Interoperability considerations: There are no known interoperability issues. Published specification: This specification. Applications that use this media type: No known applications currently use this media type. Additional information: Magic number(s): As specified for "application/xml" in [RFC3023], Section 3.2. File extension: .atomdeleted Macintosh File Type code: TEXT Person and email address to contact for further information: James M Snell Intended usage: COMMON Author/Change controller: IESG Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E0D21F8F99 for ; Sat, 3 Dec 2011 09:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62c+Inr-j0cG for ; Sat, 3 Dec 2011 09:50:19 -0800 (PST) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id 2F09721F8F5D for ; Sat, 3 Dec 2011 09:50:18 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by pechora7.dc.icann.org (8.13.8/8.13.8) with SMTP id pB3HnwLh002983 for ; Sat, 3 Dec 2011 12:50:18 -0500 Received: (qmail invoked by alias); 03 Dec 2011 17:49:55 -0000 Received: from dslb-094-222-146-017.pools.arcor-ip.net (EHLO HIVE) [94.222.146.17] by mail.gmx.net (mp011) with SMTP; 03 Dec 2011 18:49:55 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+PWAEXPiCPxC+eFZ5xwMd3xM48U8LVJtObJOjAV5 pllsosoOCEjmgh From: Bjoern Hoehrmann To: Date: Sat, 03 Dec 2011 18:49:58 +0100 Message-ID: References: <179AEF9B59A7C048B0E6626060C0D7A63F8E82BB@MX27A.corp.emc.com> In-Reply-To: <179AEF9B59A7C048B0E6626060C0D7A63F8E82BB@MX27A.corp.emc.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Sat, 03 Dec 2011 12:50:18 -0500 (EST) Cc: xacml@lists.oasis-open.org, ietf-types@iana.org Subject: Re: [ietf-types] Registration of media types application/xacmlpolicy+xml, application/xacmlrequest+xml, and application/xacmlresponse+xml X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 17:50:20 -0000 * wrote: >Section 4.10 states: > >"standards tree registrations for media types defined in documents >produced by other standards bodies MUST be described by a formal >standards specification produced by that body." > >Does that mean we first have to have a committee specification that >prescribes the use of a media type, before we can register said media >type with IANA? The general idea is that the format specification would have a section that registers the media type, but you could also have a "media types for XACML" specification or something along that line. Without that, it would still be possible to register the types through the RFC process, like when the standards organization has a format specification but does not want to update it to include the registration information and also does not want to publish a separate registration specificiation. It may also be sufficient if there is some understanding that these things will materialize within a reasonable time frame (IETF types are registered when the IESG approves an Internet-Draft for publication as RFC, but it typically takes several months before the RFC is actually published). If none of that sounds like an option, there is also the option to use different names, say `application/vnd.oasis.xacml...`. So yeah, it would be better if you have something, but the timing and the procedural formalities are not overarching concerns. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A9521F9915 for ; Fri, 2 Dec 2011 05:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8O+nnoj26vR0 for ; Fri, 2 Dec 2011 05:11:04 -0800 (PST) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id 99C3621F990A for ; Fri, 2 Dec 2011 05:11:04 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id pB2DAhJb019595 for ; Fri, 2 Dec 2011 08:11:03 -0500 Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id pB2DAdFf023752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2011 08:10:42 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 2 Dec 2011 08:10:24 -0500 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id pB2DAOFM029885; Fri, 2 Dec 2011 08:10:24 -0500 Received: from mx27a.corp.emc.com ([169.254.1.54]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Fri, 2 Dec 2011 08:10:23 -0500 From: To: Date: Fri, 2 Dec 2011 08:10:22 -0500 Thread-Topic: Registration of media types application/xacmlpolicy+xml, application/xacmlrequest+xml, and application/xacmlresponse+xml Thread-Index: Acyw87+KOX9b7yvxS8ed0sP9CE3C8g== Message-ID: <179AEF9B59A7C048B0E6626060C0D7A63F8E82BB@MX27A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Fri, 02 Dec 2011 08:11:04 -0500 (EST) X-Mailman-Approved-At: Sat, 03 Dec 2011 09:24:49 -0800 Cc: xacml@lists.oasis-open.org Subject: [ietf-types] Registration of media types application/xacmlpolicy+xml, application/xacmlrequest+xml, and application/xacmlresponse+xml X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 13:13:46 -0000 Hello, I've been authorized [1] by the OASIS XACML Technical Committee to register= 3 media types: application/xacmlpolicy+xml, application/xacmlrequest+xml, = and application/xacmlresponse+xml and have a question about the registratio= n process [2]. Section 4.10 states: "standards tree registrations for media types defined in documents produced= by other standards bodies MUST be described by a formal standards specific= ation produced by that body." Does that mean we first have to have a committee specification that prescri= bes the use of a media type, before we can register said media type with IA= NA? Thanks, Ray [1] http://lists.oasis-open.org/archives/xacml/201112/msg00006.html [2] http://tools.ietf.org/html/rfc4288