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 6FD23E074A for ; Mon, 30 May 2011 00:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.323 X-Spam-Level: X-Spam-Status: No, score=-102.323 tagged_above=-999 required=5 tests=[AWL=-0.624, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 KyiPQOV7ANWi for ; Mon, 30 May 2011 00:55:37 -0700 (PDT) Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA72E0692 for ; Mon, 30 May 2011 00:55:31 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id p4U7ssgQ027195 for ; Mon, 30 May 2011 03:55:14 -0400 Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.21]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QQeJ9-0004A8-lG; Sun, 29 May 2011 11:37:26 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <4DDA12DE.6090505@it.aoyama.ac.jp> Date: Sun, 29 May 2011 12:37:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> <4DD6B937.8000109@qualcomm.com> <011e01cc1741$9d4ec500$d7ec4f00$%roni@huawei.com> <4DD75FBE.90409@it.aoyama.ac.jp> <013b01cc1788$505c5040$f114f0c0$%roni@huawei.com> <4DDA12DE.6090505@it.aoyama.ac.jp> To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= X-Mailer: Apple Mail (2.1084) X-Greylist: Delayed for 20:15:32 by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Mon, 30 May 2011 03:55:14 -0400 (EDT) X-Mailman-Approved-At: Mon, 30 May 2011 07:00:36 -0700 Cc: 'Pete Resnick' , ietf-types@iana.org, draft-ietf-avt-rfc3016bis.all@tools.ietf.org, payload@ietf.org Subject: Re: [ietf-types] [payload] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. 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, 30 May 2011 07:55:38 -0000 On 23 May 2011, at 08:55, Martin J. D=FCrst wrote: > Just some minor nits: >=20 > Instead of things like "Security considerations: See Section 9 of this = document." and "Author: See Authors' Address section at the end of this = document." it would be better to replace "this document" with e.g. = something like [RFCxxxx], with an note to the RFC Editor/IANA to replace = [RFCxxxx] with the eventual RFC number. That way, the template can stand = alone. >=20 > Also, while "Change controller: IETF Audio/Video Transport working = group delegated from the IESG." is quite a good description of the = current reality, it's not necessarily future-proof. You don't want to go = through the registration process again just because a WG gets closed. = These registrations usually just have "The IETF" as a change controller, = with the implicit assumption that this may involve a WG and the IESG. The current phrasing was suggested by our area director when AVT started = doing media type registrations for payload formats, and lists "delegated = from the IESG" to avoid the need to redo registrations when the working = group closed. I agree it needs updating, since AVT has been replaced by = PAYLOAD, but the text was intentionally chosen to be more specific than = just "the IETF". Colin > Regards, Martin. >=20 > On 2011/05/21 16:25, Roni Even wrote: >> Hi, >> No problem. >> Here are the two registration templates and a link to the relevant = section. >> Note that it an update to existing RFC3016 registrations >> http://www.iana.org/assignments/rtp-parameters adding optional = parameters. >>=20 >> The new optional parameters are only for MP4A-LARM and they are: >> MPS-profile-level-id, MPS-asc and SBR-enabled. >>=20 >> thanks >>=20 >> Roni >>=20 >> 1. MP4V-ES >>=20 >> = http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section-6.1 >>=20 >> Type name: video >>=20 >> Subtype name: MP4V-ES >>=20 >> Required parameters: none >>=20 >> Optional parameters: >>=20 >> rate: This parameter is used only for RTP transport. It = indicates >> the resolution of the timestamp field in the RTP header. If = this >> parameter is not specified, its default value of 90000 (90kHz) = is >> used. >>=20 >> profile-level-id: A decimal representation of MPEG-4 Visual >> Profile and Level indication value = (profile_and_level_indication) >> defined in Table G-1 of [14496-2]. This parameter MAY be used = in >> the capability exchange or session setup procedure to indicate >> MPEG-4 Visual Profile and Level combination of which the MPEG-4 >> Visual codec is capable. If this parameter is not specified by >> the procedure, its default value of 1 (Simple Profile/Level 1) = is >> used. >>=20 >> config: This parameter SHALL be used to indicate the = configuration >> of the corresponding MPEG-4 Visual bitstream. It SHALL NOT be >> used to indicate the codec capability in the capability = exchange >> procedure. It is a hexadecimal representation of an octet = string >> that expresses the MPEG-4 Visual configuration information, as >> defined in subclause 6.2.1 Start codes of [14496-2]. The >> configuration information is mapped onto the octet string in an >> MSB-first basis. The first bit of the configuration = information >> SHALL be located at the MSB of the first octet. The = configuration >> information indicated by this parameter SHALL be the same as = the >> configuration information in the corresponding MPEG-4 Visual >> stream, except for first_half_vbv_occupancy and >> latter_half_vbv_occupancy, if exist, which may vary in the >> repeated configuration information inside an MPEG-4 Visual = stream >> (See 6.2.1 Start codes of [14496-2]). >>=20 >> Published specification: >>=20 >> The specifications for MPEG-4 Visual streams are presented in >> [14496-2]. The RTP payload format is described in this = document. >>=20 >> Encoding considerations: >>=20 >> Video bitstreams MUST be generated according to MPEG-4 Visual >> specifications [14496-2]. A video bitstream is binary data and >> MUST be encoded for non-binary transport (for Email, the Base64 >> encoding is sufficient). This type is also defined for = transfer >> via RTP. The RTP packets MUST be packetized according to the >> MPEG-4 Visual RTP payload format defined in this document. >>=20 >> Security considerations: >>=20 >> See Section 9 of this document. >>=20 >> Interoperability considerations: >>=20 >> MPEG-4 Visual provides a large and rich set of tools for the >> coding of visual objects. For effective implementation of the >> standard, subsets of the MPEG-4 Visual tool sets have been >> provided for use in specific applications. These subsets, = called >> 'Profiles', limit the size of the tool set a decoder is = required >> to implement. In order to restrict computational complexity, = one >> or more Levels are set for each Profile. A Profile@Level >> combination allows: >>=20 >> * a codec builder to implement only the subset of the standard = he >> needs, while maintaining interworking with other MPEG-4 = devices >> included in the same combination, and >>=20 >> * checking whether MPEG-4 devices comply with the standard >> ('conformance testing'). >>=20 >> The visual stream SHALL be compliant with the MPEG-4 Visual >> Profile@Level specified by the parameter "profile-level-id". >> Interoperability between a sender and a receiver may be = achieved >> by specifying the parameter "profile-level-id", or by arranging = a >> capability exchange/announcement procedure for this parameter. >>=20 >> Applications which use this Media Type: >>=20 >> Audio and visual streaming and conferencing tools >>=20 >> Additional information: none >>=20 >> Person and email address to contact for further information: >>=20 >> See Authors' Address section at the end of this document. >>=20 >> Intended usage: COMMON >>=20 >> Author: >>=20 >> See Authors' Address section at the end of this document. >>=20 >> Change controller: >>=20 >> IETF Audio/Video Transport working group delegated from the = IESG. >>=20 >>=20 >> 2. MP4A-LATM >>=20 >>=20 >> = http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section-6.3 >>=20 >>=20 >> Type name: audio >>=20 >> Subtype name: MP4A-LATM >>=20 >> Required parameters: >> rate: the rate parameter indicates the RTP time stamp clock = rate. >> The default value is 90000. Other rates MAY be indicated only = if >> they are set to the same value as the audio sampling rate = (number >> of samples per second). >>=20 >> In the presence of SBR, the sampling rates for the core en-/ >> decoder and the SBR tool are different in most cases. This >> parameter SHALL therefore NOT be considered as the definitive >> sampling rate. If this parameter is used, the server must >> following the rules below: >>=20 >> * When the presence of SBR is not explicitly signaled by the >> optional SDP parameters such as object parameter, profile- >> level-id or config string, this parameter SHALL be set to = the >> core codec sampling rate. >>=20 >> * When the presence of SBR is explicitly signaled by the = optional >> SDP parameters such as object parameter, profile-level-id or >> config string this parameter SHALL be set to the SBR = sampling >> rate. >>=20 >> NOTE: The optional parameter SBR-enabled in SDP a=3Dfmtp is = useful >> for implicit HE AAC / HE AAC v2 signaling. But the SBR-enabled >> parameter can also be used in the case of explicit HE AAC / HE = AAC >> v2 signaling. Therefore, its existence itself is not the = criteria >> to determine whether HE AAC / HE AAC v2 signaling is explicit = or >> not. >>=20 >> Optional parameters: >>=20 >> profile-level-id: a decimal representation of MPEG-4 Audio = Profile >> Level indication value defined in [14496-3]. This parameter >> indicates which MPEG-4 Audio tool subsets the decoder is = capable >> of using. If this parameter is not specified in the capability >> exchange or session setup procedure, its default value of 30 >> (Natural Audio Profile/Level 1) is used. >>=20 >> MPS-profile-level-id: a decimal representation of the MPEG >> Surround Profile Level indication as defined in [14496-3]. = This >> parameter indicates the support of the MPEG Surround profile = and >> level by the decoder to be capable to decode the stream. >>=20 >> object: a decimal representation of the MPEG-4 Audio Object = Type >> value defined in [14496-3]. This parameter specifies the tool = to >> be used by the decoder. It CAN be used to limit the capability >> within the specified "profile-level-id". >>=20 >> bitrate: the data rate for the audio bit stream. >>=20 >> cpresent: a boolean parameter indicates whether audio payload >> configuration data has been multiplexed into an RTP payload = (see >> Section 5.1). A 0 indicates the configuration data has not = been >> multiplexed into an RTP payload and in this case the "config" >> parameter MUST be present, a 1 indicates that it has. The = default >> if the parameter is omitted is 1. If this parameter is set to = 1 >> and the "config" parameter is present, the multiplexed >> configuration data and the value of the "config" parameter = SHALL >> be consistent. >>=20 >> config: a hexadecimal representation of an octet string that >> expresses the audio payload configuration data = "StreamMuxConfig", >> as defined in [14496-3]. Configuration data is mapped onto the >> octet string in an MSB-first basis. The first bit of the >> configuration data SHALL be located at the MSB of the first = octet. >> In the last octet, zero-padding bits, if necessary, SHALL = follow >> the configuration data. Senders MUST set the StreamMuxConfig >> elements taraBufferFullness and latmBufferFullness to their >> largest respective value, indicating that buffer fullness = measures >> are not used in SDP. Receivers MUST ignore the value of these = two >> elements contained in the config parameter. >>=20 >> MPS-asc: a hexadecimal representation of an octet string that >> expresses audio payload configuration data = "AudioSpecificConfig", >> as defined in [14496-3]. If this parameter is not present the >> relevant signaling is performed by other means (e.g. in-band or >> contained in the config string). >>=20 >> The same mapping rules as for the config parameter apply. >>=20 >> ptime: duration of each packet in milliseconds. >>=20 >> SBR-enabled: a boolean parameter which indicates whether = SBR-data >> can be expected in the RTP-payload of a stream. This parameter = is >> relevant for an SBR-capable decoder if the presence of SBR can = not >> be detected from an out-of-band decoder configuration (e.g. >> contained in the config string). >>=20 >> If this parameter is set to 0, a decoder MAY expect that SBR is >> not used. If this parameter is set to 1, a decoder CAN = upsample >> the audio data with the SBR tool, regardless whether SBR data = is >> present in the stream or not. >>=20 >> If the presence of SBR can not be detected from out-of-band >> configuration and the SBR-enabled parameter is not present, the >> parameter defaults to 1 for an SBR-capable decoder. If the >> resulting output sampling rate or the computational complexity = is >> not supported, the SBR tool can be disabled or run in = downsampled >> mode. >>=20 >> The timestamp resolution at RTP layer is determined by the rate >> parameter. >>=20 >> Published specification: >>=20 >> Encoding specifications are provided in [14496-3]. The RTP >> payload format specification is described in this document. >>=20 >> Encoding considerations: >>=20 >> This type is only defined for transfer via RTP. >>=20 >> Security considerations: >>=20 >> See Section 9 of this document. >>=20 >> Interoperability considerations: >>=20 >> MPEG-4 Audio provides a large and rich set of tools for the = coding >> of audio objects. For effective implementation of the = standard, >> subsets of the MPEG-4 Audio tool sets similar to those used in >> MPEG-4 Visual have been provided (see Section 6.1). >>=20 >> The audio stream SHALL be compliant with the MPEG-4 Audio = Profile@ >> Level specified by the parameters "profile-level-id" and "MPS- >> profile-level-id". Interoperability between a sender and a >> receiver may be achieved by specifying the parameters "profile- >> level-id" and "MPS-profile-level-id", or by arranging in the >> capability exchange procedure to set this parameter mutually to >> the same value. Furthermore, the "object" parameter can be = used >> to limit the capability within the specified Profile@Level in >> capability exchange. >>=20 >> Applications which use this media type: >>=20 >> Audio and video streaming and conferencing tools. >>=20 >> Additional information: none >>=20 >> Personal and email address to contact for further information: >>=20 >> See Authors' Address section at the end of this document. >>=20 >> Intended usage: COMMON >>=20 >> Author: >>=20 >> See Authors' Address section at the end of this document. >>=20 >> Change controller: >>=20 >> IETF Audio/Video Transport working group delegated from the = IESG. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: "Martin J. D=FCrst" [mailto:duerst@it.aoyama.ac.jp] >>> Sent: Saturday, May 21, 2011 9:46 AM >>> To: Roni Even >>> Cc: 'Pete Resnick'; draft-ietf-avt-rfc3016bis.all@tools.ietf.org; = ietf- >>> types@iana.org; 'Ali C. Begen (abegen)'; payload@ietf.org >>> Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" = and >>> "MP4V-ES" media sutypes. >>>=20 >>> Hello Roni, >>>=20 >>> I fully agree with Pete. I have often told people asking for review = on >>> this list to post the registration templates themselves. I have also >>> been on this list long enough to be able to tell you *for sure* (not >>> just 'probably' as Pete wrote) that posting the template(s) = themselves >>> really helps. >>>=20 >>> So if you haven't done it up to now, it's never too late to change = that >>> practice. Copying the template once is a little bit more work for = you >>> than just posting some pointers, but it will make it easier for all >>> reviewers on this list, because they don't have to follow your >>> instructions. >>>=20 >>> Many thanks in advance and kind regards, Martin. >>>=20 >>>=20 >>> P.S.: You didn't even bother to give a direct link to the relevant >>> section(s), which would easily be possible using = http://tools.ietf.org. >>> Of course copying the actual template is still highly preferable. >>>=20 >>>=20 >>>=20 >>> On 2011/05/21 7:59, Roni Even wrote: >>>> Pete, >>>>=20 >>>> This is what we have been doing for all payload specifications. We >>> point at >>>> the sections with the registration templates. >>>>=20 >>>> Regards >>>>=20 >>>> Roni >>>>=20 >>>>=20 >>>>=20 >>>> From: Pete Resnick [mailto:presnick@qualcomm.com] >>>> Sent: Friday, May 20, 2011 9:56 PM >>>> To: Roni Even >>>> Cc: ietf-types@iana.org; 'Ali C. Begen (abegen)'; >>>> draft-ietf-avt-rfc3016bis.all@tools.ietf.org; payload@ietf.org >>>> Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" >>> and >>>> "MP4V-ES" media sutypes. >>>>=20 >>>>=20 >>>>=20 >>>> On 4/28/11 3:30 AM, Roni Even wrote: >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in >>> the AVT >>>> Working Group (currently Payload). The document updates the media >>> subtypes >>>> "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new registrations = are >>> in >>>> Section 6.1 and Section 6.3 of the document. >>>>=20 >>>> Comments on the registration are welcome. >>>>=20 >>>>=20 >>>> Roni, it would probably help if you posted the registration = templates >>>> themselves instead of pointing to the draft. >>>>=20 >>>> Thanks, >>>>=20 >>>> pr >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> ietf-types mailing list >>>> ietf-types@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-types >>=20 >>=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload --=20 Colin Perkins http://csperkins.org/ 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 425E3E0737 for ; Sat, 28 May 2011 02:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3faK8D1CtaC9 for ; Sat, 28 May 2011 02:16:57 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [208.77.188.36]) by ietfa.amsl.com (Postfix) with ESMTP id 0C84BE0735 for ; Sat, 28 May 2011 02:16:57 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by pechora1.lax.icann.org (8.13.8/8.13.8) with SMTP id p4S9GJnA025795 for ; Sat, 28 May 2011 02:16:40 -0700 Received: (qmail invoked by alias); 28 May 2011 09:16:17 -0000 Received: from dslb-094-223-152-222.pools.arcor-ip.net (EHLO HIVE) [94.223.152.222] by mail.gmx.net (mp069) with SMTP; 28 May 2011 11:16:17 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19aYqFGdElauibDFDBH4aCwy1zCzlwqyFGwt3LscZ DsbxhHwrDFCVXy From: Bjoern Hoehrmann To: Cullen Jennings Date: Sat, 28 May 2011 11:16:20 +0200 Message-ID: <21f1u6hael1utmpg3svvn2a6s3agncb5ov@hive.bjoern.hoehrmann.de> References: <48AF46F9-5E4A-4D62-8DE0-EE6916D30F98@cisco.com> In-Reply-To: <48AF46F9-5E4A-4D62-8DE0-EE6916D30F98@cisco.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.0 (pechora1.lax.icann.org [208.77.188.36]); Sat, 28 May 2011 02:16:41 -0700 (PDT) Cc: ietf-types@iana.org, P2PSIP Mailing List Subject: Re: [ietf-types] Registration of media type application/p2p-overlay+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, 28 May 2011 09:16:57 -0000 * Cullen Jennings wrote: > To: ietf-types@iana.org > > Subject: Registration of media type application/p2p-overlay+xml There is no reason to include this part in the specification. > Type name: application > > Subtype name: p2p-overlay+xml > > Required parameters: none > > Optional parameters: none Why are you using the +xml convention but do not specify the type in a manner consistent with application/xml? Without a very good reason I'd think you should either add the "charset" parameter or drop the "+xml". > Encoding considerations: Must be binary encoded. The contents MUST > be valid XML compliant with the relax NG grammar specified in RFC- > AAAA and use the UTF-8[RFC3629] character encoding. This should either just say "binary" or just reference RFC 3023 as RFC 3023 suggests. > Interoperability considerations: Same as application/xml as defined > in [RFC3023]. If there are no known interoperability issues beyond those of the type application/xml, that is what you should say; the considerations here are certainly not the same. -- 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 A3026E0739 for ; Fri, 27 May 2011 20:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.487 X-Spam-Level: X-Spam-Status: No, score=-110.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 e3U-ffw+ZP52 for ; Fri, 27 May 2011 20:40:46 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [208.77.188.36]) by ietfa.amsl.com (Postfix) with ESMTP id 83039E06D4 for ; Fri, 27 May 2011 20:40:46 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id p4S3eB3I028405 for ; Fri, 27 May 2011 20:40:31 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1888; q=dns/txt; s=iport; t=1306554031; x=1307763631; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=Ws20X2vY9XLXb169AME4CZxhFH111u4MZg5tEZFhHjE=; b=NdtQnzDeYVmLb8nSE9GlFOEfmQZCvZ1OPLRRxpDE5wNB72kyjkba094J q9goqh24zCwraxCdwlq2lQa3uBcckG0BEzpz3cEzMMOzHTpukqY0TY7ic 6ROChl3LWxW0M3uiyNGoOqYIxzvFobovQVu6xXP0ypT4mYZbt4teFxkuU g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswGAJ1t4E2rRDoI/2dsb2JhbABVmDKOD3eoaZ08hh4EhmKJZYQ9ino X-IronPort-AV: E=Sophos;i="4.65,284,1304294400"; d="scan'208";a="365900182" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 28 May 2011 03:40:08 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4S3e7mW014161; Sat, 28 May 2011 03:40:07 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2011 21:40:06 -0600 Message-Id: <48AF46F9-5E4A-4D62-8DE0-EE6916D30F98@cisco.com> To: ietf-types@iana.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [208.77.188.36]); Fri, 27 May 2011 20:40:31 -0700 (PDT) Cc: P2PSIP Mailing List Subject: [ietf-types] Registration of media type application/p2p-overlay+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, 28 May 2011 03:40:46 -0000 The draft-ietf-p2psip-base-15 contains the following MINE Type = registration. It would appreciate any comments people wanted to send. = Thank you To: ietf-types@iana.org Subject: Registration of media type application/p2p-overlay+xml Type name: application Subtype name: p2p-overlay+xml Required parameters: none Optional parameters: none Encoding considerations: Must be binary encoded. The contents MUST be valid XML compliant with the relax NG grammar specified in RFC- AAAA and use the UTF-8[RFC3629] character encoding. Security considerations: This media type is typically not used to transport information that typically needs to be kept confidential however there are cases where it is integrity of the information is important. For these cases using a digital signature is RECOMMENDED. One way of doing this is specified in RFC-AAAA. In the case when the media includes a "shared-secret" element, then the contents of the file need to be kept confidential or else anyone that can see the shared-secret and effect the RELOAD overlay network. Interoperability considerations: Same as application/xml as defined in [RFC3023]. Published specification: RFC-AAAA Applications that use this media type: The type is used to configure the peer to peer overlay networks defined in RFC-AAAA. Additional information: The syntax for this media type is specified in Section 10.1 of RFC-AAAA. Magic number(s): none File extension(s): relo Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings 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 B1F04E07DA for ; Fri, 27 May 2011 06:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LL903e978qVT for ; Fri, 27 May 2011 06:20:55 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id E0F17E07D5 for ; Fri, 27 May 2011 06:20:54 -0700 (PDT) Received: (qmail invoked by alias); 27 May 2011 13:20:52 -0000 Received: from dslb-094-223-152-222.pools.arcor-ip.net (EHLO HIVE) [94.223.152.222] by mail.gmx.net (mp002) with SMTP; 27 May 2011 15:20:52 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/agXNsoyXanerjW6sG7Tj5imT98bFtvG+Oj0xsZY V04QOKoIBrZv3N From: Bjoern Hoehrmann To: Tim Brody Date: Fri, 27 May 2011 15:20:54 +0200 Message-ID: References: <1306501382.2146.29.camel@chassis.ecs.soton.ac.uk> 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 Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Vendor registration: 'eprints.data+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, 27 May 2011 13:21:00 -0000 * Tim Brody wrote: >EPrints is an open source document management system used in the Higher >Education sector, developed by the University of Southampton (UK). > >What name should I use for the vendor/producer? (EPrints is not >trademarked or otherwise registered) > >vnd.eprints ? This would seem fine to me, as does your proposed registration (I am not sure whether it's a good idea to specify the additional information by reference though). -- 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 8C8DEE0671 for ; Fri, 27 May 2011 06:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbaGLoBW8WNE for ; Fri, 27 May 2011 06:03:17 -0700 (PDT) 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 4C841E06EC for ; Fri, 27 May 2011 06:03:16 -0700 (PDT) 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 p4RD3AgA022549 for ; Fri, 27 May 2011 14:03:10 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p4RD3AgA022549 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1306501390; bh=6hLRTGK+wVA0jB339K4TDwrzRRE=; h=Subject:From:To:Date:Mime-Version:References; b=zUAbG7VtZdtLVLp+5522PDbvGUPHc1JhHEmCsWIeKeJ8Tpf0XqiSif3r1XmNhcixz cocHPBJFpIyfnfh2v7j2whnIO8LipW7h9gBypJsD3q7z/ZhMrbcNxg7lWYAP4GKB0D LwEx/WXNrY/vzA4Bj+FtWYyu9CM8PzTI7HdSxVLk= Received: from imap.ecs.soton.ac.uk (imap.ecs.soton.ac.uk [2001:630:d0:f102:21e:c9ff:fee7:83c0]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n4QE3A00356497265w ret-id none; Fri, 27 May 2011 14:03:10 +0100 Received: from [IPv6:2001:630:d0:f111:230:48ff:fed6:4e94] ([IPv6:2001:630:d0:f111:230:48ff:fed6:4e94]) (authenticated bits=0) by imap.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p4RD329D003090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 May 2011 14:03:02 +0100 From: Tim Brody To: ietf-types@ietf.org Content-Type: text/plain; charset="UTF-8" Date: Fri, 27 May 2011 14:03:02 +0100 Message-ID: Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n4QE38003564972600; tid=n4QE3A00356497265w; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: <1306501382.2146.29.camel@chassis.ecs.soton.ac.uk> X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p4RD3AgA022549 X-ECS-MailScanner-From: tdb2@ecs.soton.ac.uk Subject: [ietf-types] Vendor registration: 'eprints.data+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, 27 May 2011 13:07:12 -0000 Hi All, I appreciate any feedback/suggestions. EPrints is an open source document management system used in the Higher Education sector, developed by the University of Southampton (UK). What name should I use for the vendor/producer? (EPrints is not trademarked or otherwise registered) vnd.eprints ? vnd.eprints_org ? vnd.eprints.org ? Media Type Name: application Subtype name: vnd.eprints.data+xml Required parameters: None Optional parameters: charset Same as charset parameter of application/xml as specified in RFC 3023. Optional parameters: files "files='embed'" can be used during content negotiation to request files be embedded in the resulting XML. Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023. Security considerations: In addition to those of application/xml as specified in RFC 3023, section 10; the format may contain URL-references that are retrieved and embedded in the resulting digital object. If the EPrints recipient is configured to allow it these URLs may be retrieved from remote systems (via HTTP) or the recipient's file system. Interoperability considerations: None Published specification: http://wiki.eprints.org/EPData_XML_Representation Applications which use this media type: EPrints http://www.eprints.org/ Additional information: Same as additional information of application/xml as specified in RFC 3023. Intended usage: Limited Use XML serialisation of EPrints Data (or "EPData") for the import/export of the complete record. This is used for example ingesting the results of XSL transforms from standardised XML formats. The mime-type is necessary to support correct content-type negotiation when using the EPrints REST interface although the client will require knowledge of the instance's scheme. Author/Change controller: EPrints http://www.eprints.org/ Tim Brody 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 0A55CE0788 for ; Mon, 23 May 2011 07:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.332 X-Spam-Level: X-Spam-Status: No, score=-105.332 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 ZO7SOkOKqAxN for ; Mon, 23 May 2011 07:02:07 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id 1942DE0782 for ; Mon, 23 May 2011 07:02:04 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id p4NE1fml015695 for ; Mon, 23 May 2011 10:02:02 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLN00AQ7HZJD5@szxga03-in.huawei.com> for ietf-types@iana.org; Mon, 23 May 2011 21:40:31 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLN008PGHZJ1I@szxga03-in.huawei.com> for ietf-types@iana.org; Mon, 23 May 2011 21:40:31 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-15-76.red.bezeqint.net [79.181.15.76]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLN00EDKHXCIB@szxml12-in.huawei.com>; Mon, 23 May 2011 21:40:31 +0800 (CST) Date: Mon, 23 May 2011 16:37:38 +0300 From: Roni Even In-reply-to: <4DDA12DE.6090505@it.aoyama.ac.jp> To: "=?ISO-8859-1?Q?'=22Martin_J._D=FCrst=22'?=" Message-id: <004201cc194e$c23be370$46b3aa50$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=ISO-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcwZHtFqNTAqvB7ARHSSIsfWJZF6oQALs1RA References: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> <4DD6B937.8000109@qualcomm.com> <011e01cc1741$9d4ec500$d7ec4f00$%roni@huawei.com> <4DD75FBE.90409@it.aoyama.ac.jp> <013b01cc1788$505c5040$f114f0c0$%roni@huawei.com> <4DDA12DE.6090505@it.aoyama.ac.jp> X-Greylist: Delayed for 00:16:59 by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Mon, 23 May 2011 10:02:03 -0400 (EDT) Cc: 'Pete Resnick' , "'Ali C. Begen \(abegen\)'" , ietf-types@iana.org, draft-ietf-avt-rfc3016bis.all@tools.ietf.org, payload@ietf.org Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. 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, 23 May 2011 14:02:09 -0000 Hi, Good comment about AVT and the references , I will the authors to change before the registration. Regards Roni > -----Original Message----- > From: "Martin J. D=FCrst" [mailto:duerst@it.aoyama.ac.jp] > Sent: Monday, May 23, 2011 10:55 AM > To: Roni Even > Cc: 'Pete Resnick'; draft-ietf-avt-rfc3016bis.all@tools.ietf.org; = ietf- > types@iana.org; 'Ali C. Begen (abegen)'; payload@ietf.org > Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" = and > "MP4V-ES" media sutypes. >=20 > Just some minor nits: >=20 > Instead of things like "Security considerations: See Section 9 of this > document." and "Author: See Authors' Address section at the end of = this > document." it would be better to replace "this document" with e.g. > something like [RFCxxxx], with an note to the RFC Editor/IANA to > replace > [RFCxxxx] with the eventual RFC number. That way, the template can > stand > alone. >=20 > Also, while "Change controller: IETF Audio/Video Transport working > group > delegated from the IESG." is quite a good description of the current > reality, it's not necessarily future-proof. You don't want to go > through > the registration process again just because a WG gets closed. These > registrations usually just have "The IETF" as a change controller, = with > the implicit assumption that this may involve a WG and the IESG. >=20 > Regards, Martin. >=20 > On 2011/05/21 16:25, Roni Even wrote: > > Hi, > > No problem. > > Here are the two registration templates and a link to the relevant > section. > > Note that it an update to existing RFC3016 registrations > > http://www.iana.org/assignments/rtp-parameters adding optional > parameters. > > > > The new optional parameters are only for MP4A-LARM and they are: > > MPS-profile-level-id, MPS-asc and SBR-enabled. > > > > thanks > > > > Roni > > > > 1. MP4V-ES > > > > http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section- > 6.1 > > > > Type name: video > > > > Subtype name: MP4V-ES > > > > Required parameters: none > > > > Optional parameters: > > > > rate: This parameter is used only for RTP transport. It > indicates > > the resolution of the timestamp field in the RTP header. If > this > > parameter is not specified, its default value of 90000 = (90kHz) > is > > used. > > > > profile-level-id: A decimal representation of MPEG-4 Visual > > Profile and Level indication value > (profile_and_level_indication) > > defined in Table G-1 of [14496-2]. This parameter MAY be = used > in > > the capability exchange or session setup procedure to = indicate > > MPEG-4 Visual Profile and Level combination of which the = MPEG- > 4 > > Visual codec is capable. If this parameter is not specified > by > > the procedure, its default value of 1 (Simple Profile/Level = 1) > is > > used. > > > > config: This parameter SHALL be used to indicate the > configuration > > of the corresponding MPEG-4 Visual bitstream. It SHALL NOT = be > > used to indicate the codec capability in the capability > exchange > > procedure. It is a hexadecimal representation of an octet > string > > that expresses the MPEG-4 Visual configuration information, = as > > defined in subclause 6.2.1 Start codes of [14496-2]. The > > configuration information is mapped onto the octet string in > an > > MSB-first basis. The first bit of the configuration > information > > SHALL be located at the MSB of the first octet. The > configuration > > information indicated by this parameter SHALL be the same as > the > > configuration information in the corresponding MPEG-4 Visual > > stream, except for first_half_vbv_occupancy and > > latter_half_vbv_occupancy, if exist, which may vary in the > > repeated configuration information inside an MPEG-4 Visual > stream > > (See 6.2.1 Start codes of [14496-2]). > > > > Published specification: > > > > The specifications for MPEG-4 Visual streams are presented in > > [14496-2]. The RTP payload format is described in this > document. > > > > Encoding considerations: > > > > Video bitstreams MUST be generated according to MPEG-4 Visual > > specifications [14496-2]. A video bitstream is binary data > and > > MUST be encoded for non-binary transport (for Email, the > Base64 > > encoding is sufficient). This type is also defined for > transfer > > via RTP. The RTP packets MUST be packetized according to the > > MPEG-4 Visual RTP payload format defined in this document. > > > > Security considerations: > > > > See Section 9 of this document. > > > > Interoperability considerations: > > > > MPEG-4 Visual provides a large and rich set of tools for the > > coding of visual objects. For effective implementation of = the > > standard, subsets of the MPEG-4 Visual tool sets have been > > provided for use in specific applications. These subsets, > called > > 'Profiles', limit the size of the tool set a decoder is > required > > to implement. In order to restrict computational complexity, > one > > or more Levels are set for each Profile. A Profile@Level > > combination allows: > > > > * a codec builder to implement only the subset of the > standard he > > needs, while maintaining interworking with other MPEG-4 > devices > > included in the same combination, and > > > > * checking whether MPEG-4 devices comply with the standard > > ('conformance testing'). > > > > The visual stream SHALL be compliant with the MPEG-4 Visual > > Profile@Level specified by the parameter "profile-level-id". > > Interoperability between a sender and a receiver may be > achieved > > by specifying the parameter "profile-level-id", or by > arranging a > > capability exchange/announcement procedure for this = parameter. > > > > Applications which use this Media Type: > > > > Audio and visual streaming and conferencing tools > > > > Additional information: none > > > > Person and email address to contact for further information: > > > > See Authors' Address section at the end of this document. > > > > Intended usage: COMMON > > > > Author: > > > > See Authors' Address section at the end of this document. > > > > Change controller: > > > > IETF Audio/Video Transport working group delegated from the > IESG. > > > > > > 2. MP4A-LATM > > > > > > http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section- > 6.3 > > > > > > Type name: audio > > > > Subtype name: MP4A-LATM > > > > Required parameters: > > rate: the rate parameter indicates the RTP time stamp clock > rate. > > The default value is 90000. Other rates MAY be indicated = only > if > > they are set to the same value as the audio sampling rate > (number > > of samples per second). > > > > In the presence of SBR, the sampling rates for the core en-/ > > decoder and the SBR tool are different in most cases. This > > parameter SHALL therefore NOT be considered as the definitive > > sampling rate. If this parameter is used, the server must > > following the rules below: > > > > * When the presence of SBR is not explicitly signaled by the > > optional SDP parameters such as object parameter, profile- > > level-id or config string, this parameter SHALL be set to > the > > core codec sampling rate. > > > > * When the presence of SBR is explicitly signaled by the > optional > > SDP parameters such as object parameter, profile-level-id > or > > config string this parameter SHALL be set to the SBR > sampling > > rate. > > > > NOTE: The optional parameter SBR-enabled in SDP a=3Dfmtp is > useful > > for implicit HE AAC / HE AAC v2 signaling. But the SBR- > enabled > > parameter can also be used in the case of explicit HE AAC / = HE > AAC > > v2 signaling. Therefore, its existence itself is not the > criteria > > to determine whether HE AAC / HE AAC v2 signaling is explicit > or > > not. > > > > Optional parameters: > > > > profile-level-id: a decimal representation of MPEG-4 Audio > Profile > > Level indication value defined in [14496-3]. This parameter > > indicates which MPEG-4 Audio tool subsets the decoder is > capable > > of using. If this parameter is not specified in the > capability > > exchange or session setup procedure, its default value of 30 > > (Natural Audio Profile/Level 1) is used. > > > > MPS-profile-level-id: a decimal representation of the MPEG > > Surround Profile Level indication as defined in [14496-3]. > This > > parameter indicates the support of the MPEG Surround profile > and > > level by the decoder to be capable to decode the stream. > > > > object: a decimal representation of the MPEG-4 Audio Object > Type > > value defined in [14496-3]. This parameter specifies the = tool > to > > be used by the decoder. It CAN be used to limit the > capability > > within the specified "profile-level-id". > > > > bitrate: the data rate for the audio bit stream. > > > > cpresent: a boolean parameter indicates whether audio payload > > configuration data has been multiplexed into an RTP payload > (see > > Section 5.1). A 0 indicates the configuration data has not > been > > multiplexed into an RTP payload and in this case the "config" > > parameter MUST be present, a 1 indicates that it has. The > default > > if the parameter is omitted is 1. If this parameter is set = to > 1 > > and the "config" parameter is present, the multiplexed > > configuration data and the value of the "config" parameter > SHALL > > be consistent. > > > > config: a hexadecimal representation of an octet string that > > expresses the audio payload configuration data > "StreamMuxConfig", > > as defined in [14496-3]. Configuration data is mapped onto > the > > octet string in an MSB-first basis. The first bit of the > > configuration data SHALL be located at the MSB of the first > octet. > > In the last octet, zero-padding bits, if necessary, SHALL > follow > > the configuration data. Senders MUST set the StreamMuxConfig > > elements taraBufferFullness and latmBufferFullness to their > > largest respective value, indicating that buffer fullness > measures > > are not used in SDP. Receivers MUST ignore the value of = these > two > > elements contained in the config parameter. > > > > MPS-asc: a hexadecimal representation of an octet string that > > expresses audio payload configuration data > "AudioSpecificConfig", > > as defined in [14496-3]. If this parameter is not present = the > > relevant signaling is performed by other means (e.g. in-band > or > > contained in the config string). > > > > The same mapping rules as for the config parameter apply. > > > > ptime: duration of each packet in milliseconds. > > > > SBR-enabled: a boolean parameter which indicates whether SBR- > data > > can be expected in the RTP-payload of a stream. This > parameter is > > relevant for an SBR-capable decoder if the presence of SBR = can > not > > be detected from an out-of-band decoder configuration (e.g. > > contained in the config string). > > > > If this parameter is set to 0, a decoder MAY expect that SBR > is > > not used. If this parameter is set to 1, a decoder CAN > upsample > > the audio data with the SBR tool, regardless whether SBR data > is > > present in the stream or not. > > > > If the presence of SBR can not be detected from out-of-band > > configuration and the SBR-enabled parameter is not present, > the > > parameter defaults to 1 for an SBR-capable decoder. If the > > resulting output sampling rate or the computational = complexity > is > > not supported, the SBR tool can be disabled or run in > downsampled > > mode. > > > > The timestamp resolution at RTP layer is determined by the > rate > > parameter. > > > > Published specification: > > > > Encoding specifications are provided in [14496-3]. The RTP > > payload format specification is described in this document. > > > > Encoding considerations: > > > > This type is only defined for transfer via RTP. > > > > Security considerations: > > > > See Section 9 of this document. > > > > Interoperability considerations: > > > > MPEG-4 Audio provides a large and rich set of tools for the > coding > > of audio objects. For effective implementation of the > standard, > > subsets of the MPEG-4 Audio tool sets similar to those used = in > > MPEG-4 Visual have been provided (see Section 6.1). > > > > The audio stream SHALL be compliant with the MPEG-4 Audio > Profile@ > > Level specified by the parameters "profile-level-id" and = "MPS- > > profile-level-id". Interoperability between a sender and a > > receiver may be achieved by specifying the parameters > "profile- > > level-id" and "MPS-profile-level-id", or by arranging in the > > capability exchange procedure to set this parameter mutually > to > > the same value. Furthermore, the "object" parameter can be > used > > to limit the capability within the specified Profile@Level in > > capability exchange. > > > > Applications which use this media type: > > > > Audio and video streaming and conferencing tools. > > > > Additional information: none > > > > Personal and email address to contact for further information: > > > > See Authors' Address section at the end of this document. > > > > Intended usage: COMMON > > > > Author: > > > > See Authors' Address section at the end of this document. > > > > Change controller: > > > > IETF Audio/Video Transport working group delegated from the > IESG. > > > > > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: "Martin J. D=FCrst" [mailto:duerst@it.aoyama.ac.jp] > >> Sent: Saturday, May 21, 2011 9:46 AM > >> To: Roni Even > >> Cc: 'Pete Resnick'; draft-ietf-avt-rfc3016bis.all@tools.ietf.org; > ietf- > >> types@iana.org; 'Ali C. Begen (abegen)'; payload@ietf.org > >> Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" > and > >> "MP4V-ES" media sutypes. > >> > >> Hello Roni, > >> > >> I fully agree with Pete. I have often told people asking for review > on > >> this list to post the registration templates themselves. I have = also > >> been on this list long enough to be able to tell you *for sure* = (not > >> just 'probably' as Pete wrote) that posting the template(s) > themselves > >> really helps. > >> > >> So if you haven't done it up to now, it's never too late to change > that > >> practice. Copying the template once is a little bit more work for > you > >> than just posting some pointers, but it will make it easier for all > >> reviewers on this list, because they don't have to follow your > >> instructions. > >> > >> Many thanks in advance and kind regards, Martin. > >> > >> > >> P.S.: You didn't even bother to give a direct link to the relevant > >> section(s), which would easily be possible using > http://tools.ietf.org. > >> Of course copying the actual template is still highly preferable. > >> > >> > >> > >> On 2011/05/21 7:59, Roni Even wrote: > >>> Pete, > >>> > >>> This is what we have been doing for all payload specifications. We > >> point at > >>> the sections with the registration templates. > >>> > >>> Regards > >>> > >>> Roni > >>> > >>> > >>> > >>> From: Pete Resnick [mailto:presnick@qualcomm.com] > >>> Sent: Friday, May 20, 2011 9:56 PM > >>> To: Roni Even > >>> Cc: ietf-types@iana.org; 'Ali C. Begen (abegen)'; > >>> draft-ietf-avt-rfc3016bis.all@tools.ietf.org; payload@ietf.org > >>> Subject: Re: [ietf-types] updating the registeration of = "MP4A-LATM" > >> and > >>> "MP4V-ES" media sutypes. > >>> > >>> > >>> > >>> On 4/28/11 3:30 AM, Roni Even wrote: > >>> > >>> > >>> > >>> > >>> draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call = in > >> the AVT > >>> Working Group (currently Payload). The document updates the media > >> subtypes > >>> "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new registrations > are > >> in > >>> Section 6.1 and Section 6.3 of the document. > >>> > >>> Comments on the registration are welcome. > >>> > >>> > >>> Roni, it would probably help if you posted the registration > templates > >>> themselves instead of pointing to the draft. > >>> > >>> Thanks, > >>> > >>> pr > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> ietf-types mailing list > >>> ietf-types@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ietf-types > > > > Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4E7E0726 for ; Mon, 23 May 2011 00:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.741 X-Spam-Level: X-Spam-Status: No, score=-99.741 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_14=0.6, 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 LUOmXLujrluV for ; Mon, 23 May 2011 00:58:51 -0700 (PDT) Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:1::37]) by ietfa.amsl.com (Postfix) with ESMTP id AE42BE06F7 for ; Mon, 23 May 2011 00:58:48 -0700 (PDT) Received: from acspool01.acbb.aoyama.ac.jp (acspool01.acbb.aoyama.ac.jp [133.2.20.162]) by pechora2.lax.icann.org (8.13.8/8.13.8) with ESMTP id p4N7wQlY009473 for ; Mon, 23 May 2011 00:58:47 -0700 Received: from acintmta01.acbb.aoyama.ac.jp ([133.2.20.226]) by acspool01.acbb.aoyama.ac.jp (secret/secret) with ESMTP id p4N7wQo8023663 for ; Mon, 23 May 2011 16:58:26 +0900 Received: from acmse01.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta01.acbb.aoyama.ac.jp (secret/secret) with SMTP id p4N7tSGp030389 for ; Mon, 23 May 2011 16:55:28 +0900 Received: from (unknown [133.2.206.133]) by acmse01.acbb.aoyama.ac.jp with smtp id 6cf5_38cc_064d507e_8512_11e0_9daf_001d096c5b62; Mon, 23 May 2011 16:55:28 +0900 Received: from [IPv6:::1] ([133.2.210.5]:60924) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 23 May 2011 16:55:30 +0900 Message-ID: <4DDA12DE.6090505@it.aoyama.ac.jp> Date: Mon, 23 May 2011 16:55:10 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 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: Roni Even References: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> <4DD6B937.8000109@qualcomm.com> <011e01cc1741$9d4ec500$d7ec4f00$%roni@huawei.com> <4DD75FBE.90409@it.aoyama.ac.jp> <013b01cc1788$505c5040$f114f0c0$%roni@huawei.com> In-Reply-To: <013b01cc1788$505c5040$f114f0c0$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora2.lax.icann.org [208.77.188.37]); Mon, 23 May 2011 00:58:48 -0700 (PDT) Cc: 'Pete Resnick' , "'Ali C. Begen \(abegen\)'" , ietf-types@iana.org, draft-ietf-avt-rfc3016bis.all@tools.ietf.org, payload@ietf.org Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. 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, 23 May 2011 07:58:51 -0000 Just some minor nits: Instead of things like "Security considerations: See Section 9 of this document." and "Author: See Authors' Address section at the end of this document." it would be better to replace "this document" with e.g. something like [RFCxxxx], with an note to the RFC Editor/IANA to replace [RFCxxxx] with the eventual RFC number. That way, the template can stand alone. Also, while "Change controller: IETF Audio/Video Transport working group delegated from the IESG." is quite a good description of the current reality, it's not necessarily future-proof. You don't want to go through the registration process again just because a WG gets closed. These registrations usually just have "The IETF" as a change controller, with the implicit assumption that this may involve a WG and the IESG. Regards, Martin. On 2011/05/21 16:25, Roni Even wrote: > Hi, > No problem. > Here are the two registration templates and a link to the relevant section. > Note that it an update to existing RFC3016 registrations > http://www.iana.org/assignments/rtp-parameters adding optional parameters. > > The new optional parameters are only for MP4A-LARM and they are: > MPS-profile-level-id, MPS-asc and SBR-enabled. > > thanks > > Roni > > 1. MP4V-ES > > http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section-6.1 > > Type name: video > > Subtype name: MP4V-ES > > Required parameters: none > > Optional parameters: > > rate: This parameter is used only for RTP transport. It indicates > the resolution of the timestamp field in the RTP header. If this > parameter is not specified, its default value of 90000 (90kHz) is > used. > > profile-level-id: A decimal representation of MPEG-4 Visual > Profile and Level indication value (profile_and_level_indication) > defined in Table G-1 of [14496-2]. This parameter MAY be used in > the capability exchange or session setup procedure to indicate > MPEG-4 Visual Profile and Level combination of which the MPEG-4 > Visual codec is capable. If this parameter is not specified by > the procedure, its default value of 1 (Simple Profile/Level 1) is > used. > > config: This parameter SHALL be used to indicate the configuration > of the corresponding MPEG-4 Visual bitstream. It SHALL NOT be > used to indicate the codec capability in the capability exchange > procedure. It is a hexadecimal representation of an octet string > that expresses the MPEG-4 Visual configuration information, as > defined in subclause 6.2.1 Start codes of [14496-2]. The > configuration information is mapped onto the octet string in an > MSB-first basis. The first bit of the configuration information > SHALL be located at the MSB of the first octet. The configuration > information indicated by this parameter SHALL be the same as the > configuration information in the corresponding MPEG-4 Visual > stream, except for first_half_vbv_occupancy and > latter_half_vbv_occupancy, if exist, which may vary in the > repeated configuration information inside an MPEG-4 Visual stream > (See 6.2.1 Start codes of [14496-2]). > > Published specification: > > The specifications for MPEG-4 Visual streams are presented in > [14496-2]. The RTP payload format is described in this document. > > Encoding considerations: > > Video bitstreams MUST be generated according to MPEG-4 Visual > specifications [14496-2]. A video bitstream is binary data and > MUST be encoded for non-binary transport (for Email, the Base64 > encoding is sufficient). This type is also defined for transfer > via RTP. The RTP packets MUST be packetized according to the > MPEG-4 Visual RTP payload format defined in this document. > > Security considerations: > > See Section 9 of this document. > > Interoperability considerations: > > MPEG-4 Visual provides a large and rich set of tools for the > coding of visual objects. For effective implementation of the > standard, subsets of the MPEG-4 Visual tool sets have been > provided for use in specific applications. These subsets, called > 'Profiles', limit the size of the tool set a decoder is required > to implement. In order to restrict computational complexity, one > or more Levels are set for each Profile. A Profile@Level > combination allows: > > * a codec builder to implement only the subset of the standard he > needs, while maintaining interworking with other MPEG-4 devices > included in the same combination, and > > * checking whether MPEG-4 devices comply with the standard > ('conformance testing'). > > The visual stream SHALL be compliant with the MPEG-4 Visual > Profile@Level specified by the parameter "profile-level-id". > Interoperability between a sender and a receiver may be achieved > by specifying the parameter "profile-level-id", or by arranging a > capability exchange/announcement procedure for this parameter. > > Applications which use this Media Type: > > Audio and visual streaming and conferencing tools > > Additional information: none > > Person and email address to contact for further information: > > See Authors' Address section at the end of this document. > > Intended usage: COMMON > > Author: > > See Authors' Address section at the end of this document. > > Change controller: > > IETF Audio/Video Transport working group delegated from the IESG. > > > 2. MP4A-LATM > > > http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section-6.3 > > > Type name: audio > > Subtype name: MP4A-LATM > > Required parameters: > rate: the rate parameter indicates the RTP time stamp clock rate. > The default value is 90000. Other rates MAY be indicated only if > they are set to the same value as the audio sampling rate (number > of samples per second). > > In the presence of SBR, the sampling rates for the core en-/ > decoder and the SBR tool are different in most cases. This > parameter SHALL therefore NOT be considered as the definitive > sampling rate. If this parameter is used, the server must > following the rules below: > > * When the presence of SBR is not explicitly signaled by the > optional SDP parameters such as object parameter, profile- > level-id or config string, this parameter SHALL be set to the > core codec sampling rate. > > * When the presence of SBR is explicitly signaled by the optional > SDP parameters such as object parameter, profile-level-id or > config string this parameter SHALL be set to the SBR sampling > rate. > > NOTE: The optional parameter SBR-enabled in SDP a=fmtp is useful > for implicit HE AAC / HE AAC v2 signaling. But the SBR-enabled > parameter can also be used in the case of explicit HE AAC / HE AAC > v2 signaling. Therefore, its existence itself is not the criteria > to determine whether HE AAC / HE AAC v2 signaling is explicit or > not. > > Optional parameters: > > profile-level-id: a decimal representation of MPEG-4 Audio Profile > Level indication value defined in [14496-3]. This parameter > indicates which MPEG-4 Audio tool subsets the decoder is capable > of using. If this parameter is not specified in the capability > exchange or session setup procedure, its default value of 30 > (Natural Audio Profile/Level 1) is used. > > MPS-profile-level-id: a decimal representation of the MPEG > Surround Profile Level indication as defined in [14496-3]. This > parameter indicates the support of the MPEG Surround profile and > level by the decoder to be capable to decode the stream. > > object: a decimal representation of the MPEG-4 Audio Object Type > value defined in [14496-3]. This parameter specifies the tool to > be used by the decoder. It CAN be used to limit the capability > within the specified "profile-level-id". > > bitrate: the data rate for the audio bit stream. > > cpresent: a boolean parameter indicates whether audio payload > configuration data has been multiplexed into an RTP payload (see > Section 5.1). A 0 indicates the configuration data has not been > multiplexed into an RTP payload and in this case the "config" > parameter MUST be present, a 1 indicates that it has. The default > if the parameter is omitted is 1. If this parameter is set to 1 > and the "config" parameter is present, the multiplexed > configuration data and the value of the "config" parameter SHALL > be consistent. > > config: a hexadecimal representation of an octet string that > expresses the audio payload configuration data "StreamMuxConfig", > as defined in [14496-3]. Configuration data is mapped onto the > octet string in an MSB-first basis. The first bit of the > configuration data SHALL be located at the MSB of the first octet. > In the last octet, zero-padding bits, if necessary, SHALL follow > the configuration data. Senders MUST set the StreamMuxConfig > elements taraBufferFullness and latmBufferFullness to their > largest respective value, indicating that buffer fullness measures > are not used in SDP. Receivers MUST ignore the value of these two > elements contained in the config parameter. > > MPS-asc: a hexadecimal representation of an octet string that > expresses audio payload configuration data "AudioSpecificConfig", > as defined in [14496-3]. If this parameter is not present the > relevant signaling is performed by other means (e.g. in-band or > contained in the config string). > > The same mapping rules as for the config parameter apply. > > ptime: duration of each packet in milliseconds. > > SBR-enabled: a boolean parameter which indicates whether SBR-data > can be expected in the RTP-payload of a stream. This parameter is > relevant for an SBR-capable decoder if the presence of SBR can not > be detected from an out-of-band decoder configuration (e.g. > contained in the config string). > > If this parameter is set to 0, a decoder MAY expect that SBR is > not used. If this parameter is set to 1, a decoder CAN upsample > the audio data with the SBR tool, regardless whether SBR data is > present in the stream or not. > > If the presence of SBR can not be detected from out-of-band > configuration and the SBR-enabled parameter is not present, the > parameter defaults to 1 for an SBR-capable decoder. If the > resulting output sampling rate or the computational complexity is > not supported, the SBR tool can be disabled or run in downsampled > mode. > > The timestamp resolution at RTP layer is determined by the rate > parameter. > > Published specification: > > Encoding specifications are provided in [14496-3]. The RTP > payload format specification is described in this document. > > Encoding considerations: > > This type is only defined for transfer via RTP. > > Security considerations: > > See Section 9 of this document. > > Interoperability considerations: > > MPEG-4 Audio provides a large and rich set of tools for the coding > of audio objects. For effective implementation of the standard, > subsets of the MPEG-4 Audio tool sets similar to those used in > MPEG-4 Visual have been provided (see Section 6.1). > > The audio stream SHALL be compliant with the MPEG-4 Audio Profile@ > Level specified by the parameters "profile-level-id" and "MPS- > profile-level-id". Interoperability between a sender and a > receiver may be achieved by specifying the parameters "profile- > level-id" and "MPS-profile-level-id", or by arranging in the > capability exchange procedure to set this parameter mutually to > the same value. Furthermore, the "object" parameter can be used > to limit the capability within the specified Profile@Level in > capability exchange. > > Applications which use this media type: > > Audio and video streaming and conferencing tools. > > Additional information: none > > Personal and email address to contact for further information: > > See Authors' Address section at the end of this document. > > Intended usage: COMMON > > Author: > > See Authors' Address section at the end of this document. > > Change controller: > > IETF Audio/Video Transport working group delegated from the IESG. > > > > > > > > > > > > >> -----Original Message----- >> From: "Martin J. Dürst" [mailto:duerst@it.aoyama.ac.jp] >> Sent: Saturday, May 21, 2011 9:46 AM >> To: Roni Even >> Cc: 'Pete Resnick'; draft-ietf-avt-rfc3016bis.all@tools.ietf.org; ietf- >> types@iana.org; 'Ali C. Begen (abegen)'; payload@ietf.org >> Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and >> "MP4V-ES" media sutypes. >> >> Hello Roni, >> >> I fully agree with Pete. I have often told people asking for review on >> this list to post the registration templates themselves. I have also >> been on this list long enough to be able to tell you *for sure* (not >> just 'probably' as Pete wrote) that posting the template(s) themselves >> really helps. >> >> So if you haven't done it up to now, it's never too late to change that >> practice. Copying the template once is a little bit more work for you >> than just posting some pointers, but it will make it easier for all >> reviewers on this list, because they don't have to follow your >> instructions. >> >> Many thanks in advance and kind regards, Martin. >> >> >> P.S.: You didn't even bother to give a direct link to the relevant >> section(s), which would easily be possible using http://tools.ietf.org. >> Of course copying the actual template is still highly preferable. >> >> >> >> On 2011/05/21 7:59, Roni Even wrote: >>> Pete, >>> >>> This is what we have been doing for all payload specifications. We >> point at >>> the sections with the registration templates. >>> >>> Regards >>> >>> Roni >>> >>> >>> >>> From: Pete Resnick [mailto:presnick@qualcomm.com] >>> Sent: Friday, May 20, 2011 9:56 PM >>> To: Roni Even >>> Cc: ietf-types@iana.org; 'Ali C. Begen (abegen)'; >>> draft-ietf-avt-rfc3016bis.all@tools.ietf.org; payload@ietf.org >>> Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" >> and >>> "MP4V-ES" media sutypes. >>> >>> >>> >>> On 4/28/11 3:30 AM, Roni Even wrote: >>> >>> >>> >>> >>> draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in >> the AVT >>> Working Group (currently Payload). The document updates the media >> subtypes >>> "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new registrations are >> in >>> Section 6.1 and Section 6.3 of the document. >>> >>> Comments on the registration are welcome. >>> >>> >>> Roni, it would probably help if you posted the registration templates >>> themselves instead of pointing to the draft. >>> >>> Thanks, >>> >>> pr >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> ietf-types mailing list >>> ietf-types@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-types > > Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1FDE06C7 for ; Sat, 21 May 2011 00:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 1Z3n++8+X-Rz for ; Sat, 21 May 2011 00:28:00 -0700 (PDT) Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1C461E0697 for ; Sat, 21 May 2011 00:28:00 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id p4L7RNp8011648 for ; Sat, 21 May 2011 03:27:43 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLJ002CXBDLOQ@szxga04-in.huawei.com> for ietf-types@iana.org; Sat, 21 May 2011 15:27:21 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLJ009UMBDLFG@szxga04-in.huawei.com> for ietf-types@iana.org; Sat, 21 May 2011 15:27:21 +0800 (CST) Received: from windows8d787f9 ([109.64.2.135]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLJ0022XBDBXJ@szxml11-in.huawei.com>; Sat, 21 May 2011 15:27:21 +0800 (CST) Date: Sat, 21 May 2011 10:25:42 +0300 From: Roni Even In-reply-to: <4DD75FBE.90409@it.aoyama.ac.jp> To: "=?iso-8859-1?Q?'=22Martin_J._D=FCrst=22'?=" Message-id: <013b01cc1788$505c5040$f114f0c0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcwXguygBn6gIh2DRX+B9M42+tIuYgAAyU5w References: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> <4DD6B937.8000109@qualcomm.com> <011e01cc1741$9d4ec500$d7ec4f00$%roni@huawei.com> <4DD75FBE.90409@it.aoyama.ac.jp> X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Sat, 21 May 2011 03:27:44 -0400 (EDT) Cc: 'Pete Resnick' , "'Ali C. Begen \(abegen\)'" , ietf-types@iana.org, draft-ietf-avt-rfc3016bis.all@tools.ietf.org, payload@ietf.org Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. 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, 21 May 2011 07:28:00 -0000 Hi, No problem. Here are the two registration templates and a link to the relevant = section. Note that it an update to existing RFC3016 registrations http://www.iana.org/assignments/rtp-parameters adding optional = parameters. The new optional parameters are only for MP4A-LARM and they are: MPS-profile-level-id, MPS-asc and SBR-enabled. thanks Roni 1. MP4V-ES http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section-6.1 = Type name: video Subtype name: MP4V-ES Required parameters: none Optional parameters: rate: This parameter is used only for RTP transport. It indicates the resolution of the timestamp field in the RTP header. If this parameter is not specified, its default value of 90000 (90kHz) is used. profile-level-id: A decimal representation of MPEG-4 Visual Profile and Level indication value (profile_and_level_indication) defined in Table G-1 of [14496-2]. This parameter MAY be used in the capability exchange or session setup procedure to indicate MPEG-4 Visual Profile and Level combination of which the MPEG-4 Visual codec is capable. If this parameter is not specified by the procedure, its default value of 1 (Simple Profile/Level 1) is used. config: This parameter SHALL be used to indicate the configuration of the corresponding MPEG-4 Visual bitstream. It SHALL NOT be used to indicate the codec capability in the capability exchange procedure. It is a hexadecimal representation of an octet string that expresses the MPEG-4 Visual configuration information, as defined in subclause 6.2.1 Start codes of [14496-2]. The configuration information is mapped onto the octet string in an MSB-first basis. The first bit of the configuration information SHALL be located at the MSB of the first octet. The configuration information indicated by this parameter SHALL be the same as the configuration information in the corresponding MPEG-4 Visual stream, except for first_half_vbv_occupancy and latter_half_vbv_occupancy, if exist, which may vary in the repeated configuration information inside an MPEG-4 Visual stream (See 6.2.1 Start codes of [14496-2]). Published specification: The specifications for MPEG-4 Visual streams are presented in [14496-2]. The RTP payload format is described in this document. Encoding considerations: Video bitstreams MUST be generated according to MPEG-4 Visual specifications [14496-2]. A video bitstream is binary data and MUST be encoded for non-binary transport (for Email, the Base64 encoding is sufficient). This type is also defined for transfer via RTP. The RTP packets MUST be packetized according to the MPEG-4 Visual RTP payload format defined in this document. Security considerations: See Section 9 of this document. Interoperability considerations: MPEG-4 Visual provides a large and rich set of tools for the coding of visual objects. For effective implementation of the standard, subsets of the MPEG-4 Visual tool sets have been provided for use in specific applications. These subsets, called 'Profiles', limit the size of the tool set a decoder is required to implement. In order to restrict computational complexity, one or more Levels are set for each Profile. A Profile@Level combination allows: * a codec builder to implement only the subset of the standard he needs, while maintaining interworking with other MPEG-4 devices included in the same combination, and * checking whether MPEG-4 devices comply with the standard ('conformance testing'). The visual stream SHALL be compliant with the MPEG-4 Visual Profile@Level specified by the parameter "profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameter "profile-level-id", or by arranging a capability exchange/announcement procedure for this parameter. Applications which use this Media Type: Audio and visual streaming and conferencing tools Additional information: none Person and email address to contact for further information: See Authors' Address section at the end of this document. Intended usage: COMMON Author: See Authors' Address section at the end of this document. Change controller: IETF Audio/Video Transport working group delegated from the IESG. 2. MP4A-LATM http://tools.ietf.org/html/draft-ietf-payload-rfc3016bis-00#section-6.3=20 Type name: audio Subtype name: MP4A-LATM Required parameters: rate: the rate parameter indicates the RTP time stamp clock rate. The default value is 90000. Other rates MAY be indicated only if they are set to the same value as the audio sampling rate (number of samples per second). In the presence of SBR, the sampling rates for the core en-/ decoder and the SBR tool are different in most cases. This parameter SHALL therefore NOT be considered as the definitive sampling rate. If this parameter is used, the server must following the rules below: * When the presence of SBR is not explicitly signaled by the optional SDP parameters such as object parameter, profile- level-id or config string, this parameter SHALL be set to the core codec sampling rate. * When the presence of SBR is explicitly signaled by the optional SDP parameters such as object parameter, profile-level-id or config string this parameter SHALL be set to the SBR sampling rate. NOTE: The optional parameter SBR-enabled in SDP a=3Dfmtp is useful for implicit HE AAC / HE AAC v2 signaling. But the SBR-enabled parameter can also be used in the case of explicit HE AAC / HE AAC v2 signaling. Therefore, its existence itself is not the criteria to determine whether HE AAC / HE AAC v2 signaling is explicit or not. Optional parameters: profile-level-id: a decimal representation of MPEG-4 Audio Profile Level indication value defined in [14496-3]. This parameter indicates which MPEG-4 Audio tool subsets the decoder is capable of using. If this parameter is not specified in the capability exchange or session setup procedure, its default value of 30 (Natural Audio Profile/Level 1) is used. MPS-profile-level-id: a decimal representation of the MPEG Surround Profile Level indication as defined in [14496-3]. This parameter indicates the support of the MPEG Surround profile and level by the decoder to be capable to decode the stream. object: a decimal representation of the MPEG-4 Audio Object Type value defined in [14496-3]. This parameter specifies the tool to be used by the decoder. It CAN be used to limit the capability within the specified "profile-level-id". bitrate: the data rate for the audio bit stream. cpresent: a boolean parameter indicates whether audio payload configuration data has been multiplexed into an RTP payload (see Section 5.1). A 0 indicates the configuration data has not been multiplexed into an RTP payload and in this case the "config" parameter MUST be present, a 1 indicates that it has. The default if the parameter is omitted is 1. If this parameter is set to 1 and the "config" parameter is present, the multiplexed configuration data and the value of the "config" parameter SHALL be consistent. config: a hexadecimal representation of an octet string that expresses the audio payload configuration data "StreamMuxConfig", as defined in [14496-3]. Configuration data is mapped onto the octet string in an MSB-first basis. The first bit of the configuration data SHALL be located at the MSB of the first octet. In the last octet, zero-padding bits, if necessary, SHALL follow the configuration data. Senders MUST set the StreamMuxConfig elements taraBufferFullness and latmBufferFullness to their largest respective value, indicating that buffer fullness measures are not used in SDP. Receivers MUST ignore the value of these two elements contained in the config parameter. MPS-asc: a hexadecimal representation of an octet string that expresses audio payload configuration data "AudioSpecificConfig", as defined in [14496-3]. If this parameter is not present the relevant signaling is performed by other means (e.g. in-band or contained in the config string). The same mapping rules as for the config parameter apply. ptime: duration of each packet in milliseconds. SBR-enabled: a boolean parameter which indicates whether SBR-data can be expected in the RTP-payload of a stream. This parameter is relevant for an SBR-capable decoder if the presence of SBR can not be detected from an out-of-band decoder configuration (e.g. contained in the config string). If this parameter is set to 0, a decoder MAY expect that SBR is not used. If this parameter is set to 1, a decoder CAN upsample the audio data with the SBR tool, regardless whether SBR data is present in the stream or not. If the presence of SBR can not be detected from out-of-band configuration and the SBR-enabled parameter is not present, the parameter defaults to 1 for an SBR-capable decoder. If the resulting output sampling rate or the computational complexity is not supported, the SBR tool can be disabled or run in downsampled mode. The timestamp resolution at RTP layer is determined by the rate parameter. Published specification: Encoding specifications are provided in [14496-3]. The RTP payload format specification is described in this document. Encoding considerations: This type is only defined for transfer via RTP. Security considerations: See Section 9 of this document. Interoperability considerations: MPEG-4 Audio provides a large and rich set of tools for the coding of audio objects. For effective implementation of the standard, subsets of the MPEG-4 Audio tool sets similar to those used in MPEG-4 Visual have been provided (see Section 6.1). The audio stream SHALL be compliant with the MPEG-4 Audio Profile@ Level specified by the parameters "profile-level-id" and "MPS- profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameters "profile- level-id" and "MPS-profile-level-id", or by arranging in the capability exchange procedure to set this parameter mutually to the same value. Furthermore, the "object" parameter can be used to limit the capability within the specified Profile@Level in capability exchange. Applications which use this media type: Audio and video streaming and conferencing tools. Additional information: none Personal and email address to contact for further information: See Authors' Address section at the end of this document. Intended usage: COMMON Author: See Authors' Address section at the end of this document. Change controller: IETF Audio/Video Transport working group delegated from the IESG. > -----Original Message----- > From: "Martin J. D=FCrst" [mailto:duerst@it.aoyama.ac.jp] > Sent: Saturday, May 21, 2011 9:46 AM > To: Roni Even > Cc: 'Pete Resnick'; draft-ietf-avt-rfc3016bis.all@tools.ietf.org; = ietf- > types@iana.org; 'Ali C. Begen (abegen)'; payload@ietf.org > Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" = and > "MP4V-ES" media sutypes. >=20 > Hello Roni, >=20 > I fully agree with Pete. I have often told people asking for review on > this list to post the registration templates themselves. I have also > been on this list long enough to be able to tell you *for sure* (not > just 'probably' as Pete wrote) that posting the template(s) themselves > really helps. >=20 > So if you haven't done it up to now, it's never too late to change = that > practice. Copying the template once is a little bit more work for you > than just posting some pointers, but it will make it easier for all > reviewers on this list, because they don't have to follow your > instructions. >=20 > Many thanks in advance and kind regards, Martin. >=20 >=20 > P.S.: You didn't even bother to give a direct link to the relevant > section(s), which would easily be possible using = http://tools.ietf.org. > Of course copying the actual template is still highly preferable. >=20 >=20 >=20 > On 2011/05/21 7:59, Roni Even wrote: > > Pete, > > > > This is what we have been doing for all payload specifications. We > point at > > the sections with the registration templates. > > > > Regards > > > > Roni > > > > > > > > From: Pete Resnick [mailto:presnick@qualcomm.com] > > Sent: Friday, May 20, 2011 9:56 PM > > To: Roni Even > > Cc: ietf-types@iana.org; 'Ali C. Begen (abegen)'; > > draft-ietf-avt-rfc3016bis.all@tools.ietf.org; payload@ietf.org > > Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" > and > > "MP4V-ES" media sutypes. > > > > > > > > On 4/28/11 3:30 AM, Roni Even wrote: > > > > > > > > > > draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in > the AVT > > Working Group (currently Payload). The document updates the media > subtypes > > "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new registrations are > in > > Section 6.1 and Section 6.3 of the document. > > > > Comments on the registration are welcome. > > > > > > Roni, it would probably help if you posted the registration = templates > > themselves instead of pointing to the draft. > > > > Thanks, > > > > pr > > > > > > > > > > > > > > _______________________________________________ > > ietf-types mailing list > > ietf-types@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-types Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EA0E06C7 for ; Sat, 21 May 2011 00:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.045 X-Spam-Level: X-Spam-Status: No, score=-101.045 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, 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 NM5dB3TtbKdZ for ; Sat, 21 May 2011 00:10:46 -0700 (PDT) Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9A213E06AA for ; Sat, 21 May 2011 00:10:44 -0700 (PDT) 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 p4L7A5UN011119 for ; Sat, 21 May 2011 03:10:26 -0400 Received: from acintmta02.acbb.aoyama.ac.jp ([133.2.20.226]) by acspool01.acbb.aoyama.ac.jp (secret/secret) with ESMTP id p4L6nhev004559 for ; Sat, 21 May 2011 15:49:43 +0900 Received: from acmse02.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta02.acbb.aoyama.ac.jp (secret/secret) with SMTP id p4L6khcj025667 for ; Sat, 21 May 2011 15:46:44 +0900 Received: from (unknown [133.2.206.133]) by acmse02.acbb.aoyama.ac.jp with smtp id 0ad7_a54a_1732634a_8376_11e0_8720_001d0969ab06; Sat, 21 May 2011 15:46:43 +0900 Received: from [IPv6:::1] ([133.2.210.5]:33975) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 21 May 2011 15:46:48 +0900 Message-ID: <4DD75FBE.90409@it.aoyama.ac.jp> Date: Sat, 21 May 2011 15:46:22 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 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: Roni Even References: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> <4DD6B937.8000109@qualcomm.com> <011e01cc1741$9d4ec500$d7ec4f00$%roni@huawei.com> In-Reply-To: <011e01cc1741$9d4ec500$d7ec4f00$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Delayed for 00:20:20 by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Sat, 21 May 2011 03:10:27 -0400 (EDT) Cc: 'Pete Resnick' , "'Ali C. Begen \(abegen\)'" , ietf-types@iana.org, draft-ietf-avt-rfc3016bis.all@tools.ietf.org, payload@ietf.org Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. 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, 21 May 2011 07:10:47 -0000 Hello Roni, I fully agree with Pete. I have often told people asking for review on this list to post the registration templates themselves. I have also been on this list long enough to be able to tell you *for sure* (not just 'probably' as Pete wrote) that posting the template(s) themselves really helps. So if you haven't done it up to now, it's never too late to change that practice. Copying the template once is a little bit more work for you than just posting some pointers, but it will make it easier for all reviewers on this list, because they don't have to follow your instructions. Many thanks in advance and kind regards, Martin. P.S.: You didn't even bother to give a direct link to the relevant section(s), which would easily be possible using http://tools.ietf.org. Of course copying the actual template is still highly preferable. On 2011/05/21 7:59, Roni Even wrote: > Pete, > > This is what we have been doing for all payload specifications. We point at > the sections with the registration templates. > > Regards > > Roni > > > > From: Pete Resnick [mailto:presnick@qualcomm.com] > Sent: Friday, May 20, 2011 9:56 PM > To: Roni Even > Cc: ietf-types@iana.org; 'Ali C. Begen (abegen)'; > draft-ietf-avt-rfc3016bis.all@tools.ietf.org; payload@ietf.org > Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and > "MP4V-ES" media sutypes. > > > > On 4/28/11 3:30 AM, Roni Even wrote: > > > > > draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in the AVT > Working Group (currently Payload). The document updates the media subtypes > "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new registrations are in > Section 6.1 and Section 6.3 of the document. > > Comments on the registration are welcome. > > > Roni, it would probably help if you posted the registration templates > themselves instead of pointing to the draft. > > Thanks, > > pr > > > > > > > _______________________________________________ > ietf-types mailing list > ietf-types@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-types Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07ABFE0766 for ; Fri, 20 May 2011 16:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 iPQket4lAJ40 for ; Fri, 20 May 2011 16:17:23 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id 76121E06BE for ; Fri, 20 May 2011 16:17:21 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id p4KNGxdK016568 for ; Fri, 20 May 2011 19:17:20 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLI00JWFNY2Y3@szxga04-in.huawei.com> for ietf-types@iana.org; Sat, 21 May 2011 07:01:14 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLI00MH2NY2IB@szxga04-in.huawei.com> for ietf-types@iana.org; Sat, 21 May 2011 07:01:14 +0800 (CST) Received: from windows8d787f9 ([109.64.2.135]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLI001JANXSEU@szxml12-in.huawei.com>; Sat, 21 May 2011 07:01:14 +0800 (CST) Date: Sat, 21 May 2011 01:59:35 +0300 From: Roni Even In-reply-to: <4DD6B937.8000109@qualcomm.com> To: "'Pete Resnick'" Message-id: <011e01cc1741$9d4ec500$d7ec4f00$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_+UVEk8Fuqhw1eG5b0jMSGQ)" Content-language: en-us Thread-index: AcwXH7Szl29Q+QPERICvQU06PTV3pwAIa4og References: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> <4DD6B937.8000109@qualcomm.com> X-Greylist: Delayed for 00:15:44 by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Fri, 20 May 2011 19:17:20 -0400 (EDT) Cc: draft-ietf-avt-rfc3016bis.all@tools.ietf.org, ietf-types@iana.org, "'Ali C. Begen \(abegen\)'" , payload@ietf.org Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. 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, 20 May 2011 23:17:26 -0000 This is a multi-part message in MIME format. --Boundary_(ID_+UVEk8Fuqhw1eG5b0jMSGQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Pete, This is what we have been doing for all payload specifications. We point at the sections with the registration templates. Regards Roni From: Pete Resnick [mailto:presnick@qualcomm.com] Sent: Friday, May 20, 2011 9:56 PM To: Roni Even Cc: ietf-types@iana.org; 'Ali C. Begen (abegen)'; draft-ietf-avt-rfc3016bis.all@tools.ietf.org; payload@ietf.org Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. On 4/28/11 3:30 AM, Roni Even wrote: draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in the AVT Working Group (currently Payload). The document updates the media subtypes "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new registrations are in Section 6.1 and Section 6.3 of the document. Comments on the registration are welcome. Roni, it would probably help if you posted the registration templates themselves instead of pointing to the draft. Thanks, pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 --Boundary_(ID_+UVEk8Fuqhw1eG5b0jMSGQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Pete,

This is what we have been doing for all payload specifications. We point at the sections with the registration templates.

Regards

Roni

 

From: Pete Resnick! [mailto: r>Sent: Friday, May 20, 2011 9:56 PM
To: Roni Even
Cc: ietf-types@iana.org; 'Ali C. Begen (abegen)'; draft-ietf-avt-rfc3016bis.all@tools.ietf.org; payload@ietf.org
Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes.

 

On 4/28/11 3:30 AM, Roni Even wrote:


draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in the AVT Working Group (currently Payload). The document updates the media subtypes "MP4A-LATM" and "MP4V-ES"  from RFC 3016.  The new registrations are in Section 6.1 and   Section 6.3 of the document.

Comments on the registration are welcome.


Roni, ! it would ed the registration templates themselves instead of pointing to the draft.

Thanks,

pr

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
--Boundary_(ID_+UVEk8Fuqhw1eG5b0jMSGQ)-- 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 E7070E070E for ; Fri, 20 May 2011 11:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 cz8jm+iLhb4K for ; Fri, 20 May 2011 11:57:02 -0700 (PDT) Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0842BE06A6 for ; Fri, 20 May 2011 11:56:59 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id p4KIuL1q018920 for ; Fri, 20 May 2011 14:56:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1305917802; x=1337453802; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: x-originating-ip; z=Message-ID:=20<4DD6B937.8000109@qualcomm.com>|Date:=20Fr i,=2020=20May=202011=2013:55:51=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Roni=20Even=20|CC:=20,=20"'Ali=20C.=20Begen =20(abegen)'"=20,=0D=0A=09,=20 |Subject:=20Re:=20[ietf-types]=20updating=20the=20registe ration=20of=20"MP4A-LATM"=20and=09"MP4V-ES"=0D=0A=20media =20sutypes.|References:=20<00b101cc057e$821da1e0$8658e5a0 $%roni@huawei.com>|In-Reply-To:=20<00b101cc057e$821da1e0$ 8658e5a0$%roni@huawei.com>|Content-Type:=20multipart/alte rnative=3B=0D=0A=09boundary=3D"------------00070202010603 0703020000"|X-Originating-IP:=20[172.30.48.1]; bh=CQziePoet1iIoyoGy27Ffq/H8d6C2I7sAJdSdPrsHZ8=; b=VUoHSHv+c3ChOIDyRdUB39GGsCeMv8htIWLuOHsTSxhx8aoQaCLtCJ0T gJ3p+VTCgQU2855xqzx5PoaC4iY2hQQM2rYqP+nn055VtBVUaWoq2MQRb vf/l0oGC/mV9RF7eiUmowRNXihv2Qnr6mo2CVKEROAeOGcw6V3XRBWJKP 8=; X-IronPort-AV: E=McAfee;i="5400,1158,6351"; a="92571723" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 20 May 2011 11:56:20 -0700 X-IronPort-AV: E=Sophos;i="4.65,242,1304319600"; d="scan'208,217";a="56005578" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 20 May 2011 11:56:20 -0700 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 20 May 2011 11:55:53 -0700 Message-ID: <4DD6B937.8000109@qualcomm.com> Date: Fri, 20 May 2011 13:55:51 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Roni Even References: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> In-Reply-To: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> Content-Type: multipart/alternative; boundary="------------000702020106030703020000" X-Originating-IP: [172.30.48.1] X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Fri, 20 May 2011 14:56:42 -0400 (EDT) Cc: draft-ietf-avt-rfc3016bis.all@tools.ietf.org, ietf-types@iana.org, "'Ali C. Begen \(abegen\)'" , payload@ietf.org Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. 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, 20 May 2011 18:57:03 -0000 --------------000702020106030703020000 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 4/28/11 3:30 AM, Roni Even wrote: > draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in > the AVT Working Group (currently Payload). The document updates the > media subtypes "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new > registrations are in Section 6.1 and Section 6.3 of the document. > > Comments on the registration are welcome. > Roni, it would probably help if you posted the registration templates themselves instead of pointing to the draft. Thanks, pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 --------------000702020106030703020000 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 4/28/11 3:30 AM, Roni Even wrote:

draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in the AVT Working Group (currently Payload). The document updates the media subtypes "MP4A-LATM" and "MP4V-ES"  from RFC 3016.  The new registrations are in Section 6.1 and   Section 6.3 of the document.

Comments on the registration are welcome.


Roni, it would probably help if you posted the registration templates themselves instead of pointing to the draft.

Thanks,

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
--------------000702020106030703020000-- 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 D7AE6E06BE for ; Thu, 19 May 2011 11:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_33=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 VQutoFfheaT6 for ; Thu, 19 May 2011 11:55:26 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEF8E06AD for ; Thu, 19 May 2011 11:55:25 -0700 (PDT) Received: from sf00.oasis-open.org (sf00.oasis-open.org [66.151.234.58]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id p4JIt3wS002698 for ; Thu, 19 May 2011 11:55:24 -0700 Received: from static-72-248-225-154.ngn.onecommunications.net ([72.248.225.154] helo=fs00.ma0.oasis-open.net) by sf00.oasis-open.org with esmtp id 1QN7OQ-0004l3-UT; Thu, 19 May 2011 13:52:21 -0400 Received: from rcover (helo=localhost) by fs00.ma0.oasis-open.net with local-esmtp (Exim 4.69) (envelope-from ) id 1QN7OL-0003y9-AV; Thu, 19 May 2011 13:52:09 -0400 Date: Thu, 19 May 2011 13:52:09 -0400 (EDT) From: Robin Cover X-X-Sender: rcover@fs00.ma0.oasis-open.net To: "Media (MIME) Type Review List" In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1492452631-1305827529=:7188" X-Antivirus-Scanner: ClamAV at OASIS detected no problems X-Greylist: Delayed for 01:02:33 by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Thu, 19 May 2011 11:55:24 -0700 (PDT) Cc: Drummond Reed , "Media \(MIME\) Type Review List" , Bjoern Hoehrmann Subject: Re: [ietf-types] Registration of media type xrd+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: Thu, 19 May 2011 18:55:28 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1492452631-1305827529=:7188 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Bjoern, thank you for the feedback. One of the TC Chairs has been copied, so we will ensure that your questions are addressed by the principals. The reqistration request was constructed (mostly verbatim) from an older OASIS specification, so there may be relevant updates (e.g., WRT "Applications that use this media type") I'll continue to monitor this list for additional comments by the reviewers. Kindest regards and best wishes, - Robin Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/who/staff.php#cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783 On Thu, 19 May 2011, Bjoern Hoehrmann wrote: > * Robin Cover wrote: >> Applications that use this media type: No known >> applications currently use this media type. > > This field should identify what kind of application would use the type > like word processors or vector graphics editing applications; it is not > supposed to indentify individual products. > > I am not sure I follow what you are saying with respect to the removal > of the media type registration template from the OASIS specifications. > What properly published document currently includes the template, or > which will be edited "soon" so it includes the template? > --=20 > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld= =2Ede > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev= =2Ede/ > --8323329-1492452631-1305827529=:7188-- 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 B77E6E07D1 for ; Thu, 19 May 2011 08:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, J_CHICKENPOX_33=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 HgFex5I-8EHn for ; Thu, 19 May 2011 08:14:27 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [208.77.188.38]) by ietfa.amsl.com (Postfix) with ESMTP id C90BAE070B for ; Thu, 19 May 2011 08:14:25 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pechora3.lax.icann.org (8.13.8/8.13.8) with SMTP id p4JFDn4F021575 for ; Thu, 19 May 2011 08:14:09 -0700 Received: (qmail invoked by alias); 19 May 2011 15:13:46 -0000 Received: from dslb-094-223-211-072.pools.arcor-ip.net (EHLO HIVE) [94.223.211.72] by mail.gmx.net (mp056) with SMTP; 19 May 2011 17:13:46 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+02gsQEYe0eof5oenIdFfFlKykIF3Z0qB4woFWmk KIyIdC1xzJ21U8 From: Bjoern Hoehrmann To: Robin Cover Date: Thu, 19 May 2011 17:13:48 +0200 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: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [208.77.188.38]); Thu, 19 May 2011 08:14:10 -0700 (PDT) Cc: "Media \(MIME\) Type Review List" , Drummond Reed Subject: Re: [ietf-types] Registration of media type xrd+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: Thu, 19 May 2011 15:14:28 -0000 * Robin Cover wrote: >Applications that use this media type: No known >applications currently use this media type. This field should identify what kind of application would use the type like word processors or vector graphics editing applications; it is not supposed to indentify individual products. I am not sure I follow what you are saying with respect to the removal of the media type registration template from the OASIS specifications. What properly published document currently includes the template, or which will be edited "soon" so it includes the template? -- 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 3B2EDE0751 for ; Thu, 19 May 2011 08:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_33=0.6, J_CHICKENPOX_84=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 igMoF4jLRTB9 for ; Thu, 19 May 2011 08:03:27 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [208.77.188.38]) by ietfa.amsl.com (Postfix) with ESMTP id 35EAAE07E5 for ; Thu, 19 May 2011 08:03:19 -0700 (PDT) Received: from sf01.oasis-open.org (sf01.oasis-open.org [66.151.234.57]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id p4JF2gOL020848 for ; Thu, 19 May 2011 08:03:02 -0700 Received: from static-72-248-225-154.ngn.onecommunications.net ([72.248.225.154] helo=fs00.ma0.oasis-open.net) by sf01.oasis-open.org with esmtp id 1QN4QO-0008EA-CW; Thu, 19 May 2011 10:42:09 -0400 Received: from rcover (helo=localhost) by fs00.ma0.oasis-open.net with local-esmtp (Exim 4.69) (envelope-from ) id 1QN4QI-0007KM-U8; Thu, 19 May 2011 10:41:58 -0400 Date: Thu, 19 May 2011 10:41:58 -0400 (EDT) From: Robin Cover X-X-Sender: rcover@fs00.ma0.oasis-open.net To: "Media (MIME) Type Review List" Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Antivirus-Scanner: ClamAV at OASIS detected no problems X-Greylist: Delayed for 00:20:31 by milter-greylist-4.0 (pechora3.lax.icann.org [208.77.188.38]); Thu, 19 May 2011 08:03:02 -0700 (PDT) Cc: Drummond Reed Subject: [ietf-types] Registration of media type xrd+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: Thu, 19 May 2011 15:03:28 -0000 Type name: application Subtype name: xrd+xml Required parameters: None Optional parameters: "charset": This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in RFC 3023 http://tools.ietf.org/html/rfc3023 Encoding considerations: Identical to those of application/xml as described by RFC 3023 section 3.2 http://tools.ietf.org/html/rfc3023#section-3.2 Security considerations: [Are] As defined in this specification [viz., "Extensible Resource Descriptor (XRD) Version 1.0", Committee Draft 02, 9 March 2010, superseded by the approved OASIS Standard. 1 November 2010 http://docs.oasis-open.org/xri/xrd/v1.0/os/xrd-1.0-os.html ] In addition, as this media type uses the "+xml" convention, it shares the same security considerations as described in RFC 3023, Section 10 http://tools.ietf.org/html/rfc3023#section-10 Interoperability considerations: There are no known interoperability issues. Published specification: The latest approved version is "Extensible Resource Descriptor (XRD) Version 1.0", OASIS Standard, 1 November 2010 available at: http://docs.oasis-open.org/xri/xrd/v1.0/os/xrd-1.0-os.xml http://docs.oasis-open.org/xri/xrd/v1.0/os/xrd-1.0-os.html http://www.oasis-open.org/standards#xrdv1.0 The specification was approved (twice) at Committee Draft level with "Appendix C. Media Type Definition for application/xrd+xml (Non-Normative)". In connection with Committee Draft 03, the Appendix was removed on the basis of a decision to apply for the media/mime type registration after the XRD specification was a final approved OASIS Standard. See: http://docs.oasis-open.org/xri/xrd/v1.0/cd02/xrd-1.0-cd02.html#media-type http://docs.oasis-open.org/xri/xrd/v1.0/cd01/xrd-1.0-cd01.html#media-type Applications that use this media type: No known applications currently use this media type. Additional information: Magic number(s): As specified for RFC 3023 section 3.2 http://tools.ietf.org/html/rfc3023#section-3.2 File extension(s): None Macintosh file type code(s): TEXT Person & email address to contact for further information: Drummond Reed, OASIS Extensible Resource Identifier (XRI) TC Chair Email: drummond.reed AT xdi.org TC: http://www.oasis-open.org/committees/xri/ Intended usage: COMMON Restrictions on usage: None Author: OASIS Extensible Resource Identifier (XRI) Technical Committee Change controller: OASIS Extensible Resource Identifier (XRI) Technical Committee, c/o Drummond Reed (Chair), drummond.reed AT xdi.org Other information: The OASIS XRI Technical Committee voted to remove the "Appendix C. Media Type Definition for application/xrd+xml" in the approved Committee Specification so that the registration request could be made once the specification became a final OASIS Standard. See: http://lists.oasis-open.org/archives/xri/201104/msg00000.html Subject: Registration of application/xrd+xml with IETF From: Drummond Reed Date: Sat, 16 Apr 2011 11:00:52 -0700 Scott, I'm sending this question to you because Mary McRae is no longer with OASIS. After XRD 1.0 became an OASIS Standard last November 1, OASIS was supposed to register the MIME type application/xrd+xml with IETF. Eran Hammer-Lahav just checked and no sign of it. Can you find out what became of it? We need to get this registered as soon as we can. See also: http://lists.oasis-open.org/archives/xri/201006/msg00020.html http://lists.oasis-open.org/archives/xri-comment/201006/msg00002.html http://lists.oasis-open.org/archives/xri/201006/msg00018.html http://lists.oasis-open.org/archives/xri/201007/msg00025.html http://lists.oasis-open.org/archives/xri/201011/msg00007.html Submitted by Robin Cover for the OASIS TC Administration and the OASIS Extensible Resource Identifier (XRI) Technical Committee. Email: robin AT oasis-open.org -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783 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 43F3EE069E for ; Tue, 17 May 2011 00:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.166 X-Spam-Level: X-Spam-Status: No, score=0.166 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] 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 CUW373SLX4eO for ; Tue, 17 May 2011 00:22:59 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id D54CDE067F for ; Tue, 17 May 2011 00:22:57 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id p4H7Makh016007 for ; Tue, 17 May 2011 00:22:56 -0700 Received: from ip-109-41-228-113.web.vodafone.de (ip-109-41-228-113.web.vodafone.de [109.41.228.113]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0Mhrl9-1Q02vK15Hf-00MvJ4; Tue, 17 May 2011 09:22:34 +0200 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-14-892237391 From: Paul Libbrecht In-Reply-To: <009001cc0bd8$6f84d700$4e8e8500$@org> Date: Tue, 17 May 2011 09:22:31 +0200 Message-Id: References: <009001cc0bd8$6f84d700$4e8e8500$@org> To: Michael Steidl (IPTC) X-Mailer: Apple Mail (2.1078) X-Provags-ID: V02:K0:rRcLZv4YTid4D3Y0BTArSev7wz4y/3sV7INS6zIyB2f 2LlE3L6o5lcnxU6ni/65vJLfIuwEWZkHERGumBG+IkcyeX3miV gVJpiYoF/YY/VjS9S57cahYOm6vppaOfWr1NDufn8ccBrDcXEs AdpQIyqCVZW8Y/AhWFr3E+dNMEoE5zrzXy6u8vbv+Dk/IaX5Jk tEeGNEpyHaMP20b+lI7f5dppatzX6O+9+XGnCV68N4= X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Tue, 17 May 2011 00:22:56 -0700 (PDT) Cc: ietf-types@iana.org Subject: Re: [ietf-types] Registration of media type application/vnd.iptc.g2.planningitem+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: Tue, 17 May 2011 07:23:00 -0000 --Apple-Mail-14-892237391 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Michael, I would like to suggest to add the following two lines in the = "Additional information" section: - Windows Clipboard Flavor Name: "IPTC Planningitem XML" - Macintosh Uniform Type Identifier: org.iptc.planningitem conforms to = public.xml The objective is to make sure that these names are used when items of = this type are put into the clipboard of these operating systems. paul Le 6 mai 2011 =E0 12:29, Michael Steidl (IPTC) a =E9crit : > To: ietf-types@iana.org > =20 > Subject: > Registration of media type application/vnd.iptc.g2.planningitem+xml > =20 > Media Type Name: application > =20 > Subtype name: vnd.iptc.g2.planningitem+xml > =20 > Required parameters: none > =20 > Optional parameters: charset > identical to the charset parameter on application/xml as described > in RFC 3023 [RFC3023] section 3.2 > =20 > Encoding considerations: Identical to those of application/xml as > described in RFC 3023, section 3.2 > =20 > Security considerations: In regards to general XML Security issues, > identical to those of "application/xml" as described in RFC3023, > section 10. Beyond these general XML Security issues, the media > type does not contain active or executable content. The information > contained in the media type does not require privacy or integrity > services, however the media type does support the use of the XML > syntax and processing rules for creating and representing digital > signatures as described by RFC3275. > =20 > Interoperability considerations: > =20 > Published specification: > =20 > for NewsML-G2 version 2.7 specifications and EventsML-G2 version 1.6 = specifications > =20 > = http://www.iptc.org/std/NAR/1.8/specification/NAR_1.8-spec-PlanningItem-Co= re.xsd > =20 > Or > =20 > = http://www.iptc.org/std/NAR/1.8/specification/NAR_1.8-spec-PlanningItem-Po= wer.xsd > =20 > Applications which use this media type: none > =20 > Additional information: > =20 > Magic number(s): none > =20 > File extension(s): .xml > =20 > Macintosh File Type Code(s): Identical to those of > "application/xml" as described in RFC3023, "TEXT" > =20 > Object Identifier(s) or OID(s): > It must be possible to positively identify an Item as it moves > through the news workflow, and is transferred from place to place > and from system to system. An Item therefore gets a globally > unique identifier (guid), which is a persistent, universally unique > identifier, and a version which is incremented when the content of > the Item is updated. The first version is numbered 1: if the version > is not explicitly set, this value must be assumed by the recipient of > the Item. The guid is required to be in the form of a IRI. Any IRI > capable of acting as a globally unique identifier is accepted; the > IPTC provides a standard for this purpose in the form of an IETF RFC > [RFC-3085]. > =20 > Intended usage: > =20 > A Planning Item conveys information for the editorial staff of > media companies about the planned coverage of events or topics > by a news provider. > Typically a Planning Item holds details like the headline, > keywords and the time of release for a set of planned News Items, > Concept Items or Package items. Further a Planning Item > may provide a list of already delivered Items. > =20 > Other Information/General Comment: none > =20 > Person to contact for further information: > Name: Michael Steidl > E-mail: mdirector@iptc.org > =20 > Author/Change controller: > Name: Michael Steidl > E-mail: mdirector@iptc.org > =20 > ----------------------------- > =20 > Michael Steidl > Managing Director of the IPTC [mdirector@iptc.org] > International Press Telecommunications Council=20 > Web: www.iptc.org - on Twitter @IPTC > Business office address: > 20 Garrick Street, London WC2E 9BT, United Kingdom > Registered in England, company no 101096 > =20 > _______________________________________________ > ietf-types mailing list > ietf-types@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-types --Apple-Mail-14-892237391 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

- Windows Clipboard Flavor Name: "IPTC = Planningitem XML"
- Macintosh Uniform Type Identifier: = org.iptc.planningitem conforms to = public.xml

The objective is to make sure that = these names are used when items of this type are put into the clipboard = of these operating = systems.

paul


L= e 6 mai 2011 =E0 12:29, Michael Steidl (IPTC) a =E9crit :

To:  
Business office address:
20 Garrick Street, London WC2E = 9BT, United Kingdom
Registered in England, company no = 101096
 
_______________________= ________________________
ietf-types mailing list
ietf-types@ietf.org
,=0D=0A=09,=20 |Subject:=20Re:=20[ietf-types]=20updating=20the=20registe ration=20of=20"MP4A-LATM"=20and=09"MP4V-ES"=0D=0A=20media =20sutypes.|X-Priority:=202=20(High)|References:=20<00b10 1cc057e$821da1e0$8658e5a0$%roni@huawei.com>|In-Reply-To: =20<00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"------------010600010401050803030103" |X-Originating-IP:=20[172.30.39.5]; bh=M8BoqbXoroggCHtzdMkecmbx7AmAMwHvNE2fgg44n3E=; b=AEzOYKSTTz/9kegTYwJ5TXeRNm8f07RyI+NkU+Ka70HYGO0Qnn1V66LS 0UB+lLnbgpTUtIWrhJQpmeDR+2tOQI9Dpn7VRvUwk0jcfiY4iumcL2EMz txfb50fZlj5tbSJoMRt2a1ItBn1QpnoVj27ZXnRBuaubaH2OJBO+Y+SjV U=; X-IronPort-AV: E=McAfee;i="5400,1158,6348"; a="91483369" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 16 May 2011 13:29:58 -0700 X-IronPort-AV: E=Sophos;i="4.64,374,1301900400"; d="scan'208,217";a="53730119" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 16 May 2011 13:29:58 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 16 May 2011 13:29:58 -0700 Message-ID: <4DD18944.8030701@qualcomm.com> Date: Mon, 16 May 2011 15:29:56 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Roni Even X-Priority: 2 (High) References: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> In-Reply-To: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> Content-Type: multipart/alternative; boundary="------------010600010401050803030103" X-Originating-IP: [172.30.39.5] X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora2.lax.icann.org [208.77.188.37]); Mon, 16 May 2011 13:30:34 -0700 (PDT) Cc: draft-ietf-avt-rfc3016bis.all@tools.ietf.org, ietf-types@iana.org, "'Ali C. Begen \(abegen\)'" , payload@ietf.org Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. 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, 16 May 2011 20:30:36 -0000 --------------010600010401050803030103 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Did anyone review this? I have seen no responses. pr On 4/28/11 3:30 AM, Roni Even wrote: > > Hi, > > draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in > the AVT Working Group (currently Payload). The document updates the > media subtypes "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new > registrations are in Section 6.1 and Section 6.3 of the document. > > Comments on the registration are welcome. > > Thanks > > Roni Even > > Payload WG co-chair > -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 --------------010600010401050803030103 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Did anyone review this? I have seen no responses.

pr

On 4/28/11 3:30 AM, Roni Even wrote:

 

Hi,

 

draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in the AVT Working Group (currently Payload). The document updates the media subtypes "MP4A-LATM" and "MP4V-ES"  from RFC 3016.  The new registrations are in Section 6.1 and   Section 6.3 of the document.

Comments on the registration are welcome.

 

Thanks

Roni Even

Payload WG co-chair


-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
--------------010600010401050803030103-- 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 91C2DE072E for ; Mon, 9 May 2011 14:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.144 X-Spam-Level: X-Spam-Status: No, score=-104.144 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-4, 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 4bXup+LVDvre for ; Mon, 9 May 2011 14:13:54 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF6EE067B for ; Mon, 9 May 2011 14:13:54 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id p49LDUaR030458 for ; Mon, 9 May 2011 17:13:50 -0400 Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKTchY+TTHipw7gjUHBi8iqJ0oIbAJ6JTT@postini.com; Mon, 09 May 2011 14:13:52 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p49LDSEU016891; Mon, 9 May 2011 14:13:28 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id p49LDR1R021048; Mon, 9 May 2011 14:13:28 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Mon, 9 May 2011 14:13:27 -0700 From: Peeter Piegaze To: "ietf-types@iana.org" Date: Mon, 9 May 2011 14:13:25 -0700 Thread-Topic: Registration of media type text/jcr-cnd Thread-Index: AcwOje9aR4310N+WSoe/a+n/5/fQZA== Message-ID: <49F4A4B3338A05419CA5CCF34300F5BD07AE71023C@nambx05.corp.adobe.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-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Mon, 09 May 2011 17:13:53 -0400 (EDT) X-Mailman-Approved-At: Mon, 09 May 2011 14:29:33 -0700 Cc: Pete Resnick , David Nuescheler Subject: [ietf-types] Registration of media type text/jcr-cnd 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, 09 May 2011 21:13:57 -0000 Type name: text Subtype name: jcr-cnd Required parameters: None Optional parameters: None Encoding considerations: 8 bit (UTF-8) Security considerations: None known Interoperability considerations: None Published specification: JSR-283 Content Repository Specification for Java = Technology (JCR) (http://jcp.org/en/jsr/detail?id=3D283). See especially sections 3.7 and 25= .2.=20 If approved, this MIME type will be included in the next revision of JCR, which is under development as JCR-333 (http://jcp.org/en/jsr/detail?id=3D33= 3) Applications that use this media type: Used by content repositories that im= plement the Content Repository For Java API (JCR)=20 Additional information: File extension(s): .cnd Person & email address to contact for further information: Peeter Piegaze ppiegaze@adobe.com David Nuescheler uncled@adobe.com Intended usage: Common Restrictions on usage: None Author: JSR-333 Expert Group Change controller: Peeter Piegaze ppiegaze@adobe.com Files of this media type define node types in JCR-compliant content reposit= ories. Nodes are the structural components that make up the content storage= in a JCR repository. A node type defines the characteristics that a node c= an have. Files of this media type are typically processed by a repository, = thus registering the defined node types, making them available to users of = the repository. Files of this media type are typically referred to as Compa= ct Node Type Definition files or CND files. 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 9280DE0705 for ; Mon, 9 May 2011 14:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=-2.363, BAYES_05=-1.11] 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 erg60vl56M2I for ; Mon, 9 May 2011 14:12:40 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [208.77.188.36]) by ietfa.amsl.com (Postfix) with ESMTP id 56584E069C for ; Mon, 9 May 2011 14:12:39 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by pechora1.lax.icann.org (8.13.8/8.13.8) with SMTP id p49LC3L4022667 for ; Mon, 9 May 2011 14:12:24 -0700 Received: (qmail invoked by alias); 09 May 2011 21:12:01 -0000 Received: from dslb-094-223-189-018.pools.arcor-ip.net (EHLO HIVE) [94.223.189.18] by mail.gmx.net (mp071) with SMTP; 09 May 2011 23:12:01 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19e7UBttA1ejUKUshIhDbQaBLvhPbxTZo+94+xBJg wRwgih+tPE7lFS From: Bjoern Hoehrmann To: Julian Reschke Date: Mon, 09 May 2011 23:12:12 +0200 Message-ID: <22mgs6965sehtoqcbvq2rtcnclkhoj7v1o@hive.bjoern.hoehrmann.de> References: <4DC850CE.7020906@gmx.de> In-Reply-To: <4DC850CE.7020906@gmx.de> 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.0 (pechora1.lax.icann.org [208.77.188.36]); Mon, 09 May 2011 14:12:24 -0700 (PDT) Cc: "ietf-types@iana.org" Subject: Re: [ietf-types] Fwd: Request for MIME media type text/jcr-cnd 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, 09 May 2011 21:12:41 -0000 * Julian Reschke wrote: >Forwarding... did this ever reach the mailing list? It's not in my archives and my favourite search engine cannot locate it on the web either, so, probably not. You can download the raw archives to make sure from the IETF FTP server, if you really cared. Might be stuck in the moderator's queue. -- 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 83CA6E091E for ; Mon, 9 May 2011 13:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.463 X-Spam-Level: X-Spam-Status: No, score=-103.463 tagged_above=-999 required=5 tests=[AWL=-3.319, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 4nPyzvQNnPqu for ; Mon, 9 May 2011 13:39:18 -0700 (PDT) Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) by ietfa.amsl.com (Postfix) with ESMTP id A5DA9E07C8 for ; Mon, 9 May 2011 13:39:18 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pechora8.dc.icann.org (8.13.8/8.13.8) with SMTP id p49KcfnH028302 for ; Mon, 9 May 2011 16:39:02 -0400 Received: (qmail invoked by alias); 09 May 2011 20:38:39 -0000 Received: from p508FD26B.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.210.107] by mail.gmx.net (mp010) with SMTP; 09 May 2011 22:38:39 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18QfjJgOk4QtjAz2uCpN8cVapiq8iKgHqaCMTgHv+ ihNRc0rOy7AGR1 Message-ID: <4DC850CE.7020906@gmx.de> Date: Mon, 09 May 2011 22:38:38 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "ietf-types@iana.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Mon, 09 May 2011 16:39:02 -0400 (EDT) Subject: [ietf-types] Fwd: Request for MIME media type text/jcr-cnd 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, 09 May 2011 20:39:19 -0000 Forwarding... did this ever reach the mailing list? -------- Original Message -------- Subject: Request for MIME media type text/jcr-cnd Date: Mon, 28 Mar 2011 14:38:08 -0700 From: Peeter Piegaze To: ietf-types@iana.org CC: David Nuescheler , "julian.reschke@gmx.de" Media Type Name: text Subtype name: jcr-cnd Required parameters: None. Optional parameters: None. Encoding considerations: 8 bit (UTF-8). Security considerations: None known. Interoperability considerations: None. Published specification: http://jcp.org/en/jsr/detail?id=283. See especially sections 3.7 and 25.2. Applications which use this media type: Used by content repositories that implement the Content Repository For Java API (JCR). File extension: .cnd Intended usage: Files of this media type define node types in JCR-compliant content repositories. Nodes are the structural components that make up the content storage in a JCR repository. A node type defines the characteristics that a node can have. Files of this media type are typically processed by a repository, thus registering the defined node types, making them available to users of the repository. Files of this media type are typically referred to as Compact Node Type Definition files or CND files. Persons to contact for further information: David Nuescheler Adobe Systems uncled@adobe.com Peeter Piegaze Adobe Systems ppiegaze@adobe.com 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 5A26BE0803 for ; Mon, 9 May 2011 13:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.017 X-Spam-Level: X-Spam-Status: No, score=-104.017 tagged_above=-999 required=5 tests=[AWL=-2.907, BAYES_05=-1.11, 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 5n845W1CjL3W for ; Mon, 9 May 2011 13:34:19 -0700 (PDT) Received: from pechora6.dc.icann.org (pechora6.icann.org [192.0.46.72]) by ietfa.amsl.com (Postfix) with ESMTP id BD5C1E07C8 for ; Mon, 9 May 2011 13:34:19 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pechora6.dc.icann.org (8.13.8/8.13.8) with SMTP id p49KXhLs025526 for ; Mon, 9 May 2011 16:34:03 -0400 Received: (qmail invoked by alias); 09 May 2011 20:33:40 -0000 Received: from p508FD26B.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.210.107] by mail.gmx.net (mp058) with SMTP; 09 May 2011 22:33:40 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18012I20+Y0o3Bze4eq2rY6Pq97CjU+uSEfrky44k FT4kojh3pP3889 Message-ID: <4DC84FA1.5060704@gmx.de> Date: Mon, 09 May 2011 22:33:37 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: ietf-types@iana.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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, 09 May 2011 16:34:04 -0400 (EDT) Subject: [ietf-types] mail test 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, 09 May 2011 20:34:20 -0000 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 F0545E0709 for ; Fri, 6 May 2011 03:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] 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 i7P8HEFQ0xjs for ; Fri, 6 May 2011 03:56:29 -0700 (PDT) Received: from pechora6.dc.icann.org (pechora6.icann.org [192.0.46.72]) by ietfa.amsl.com (Postfix) with ESMTP id BB67AE064B for ; Fri, 6 May 2011 03:56:28 -0700 (PDT) Received: from mail.iptc.org (srvhost34.serverhosting.apa.net [194.232.153.97]) by pechora6.dc.icann.org (8.13.8/8.13.8) with ESMTP id p46AtpYY015143 for ; Fri, 6 May 2011 06:56:12 -0400 Received: from NITFIX7 (unknown [83.64.11.70]) (Authenticated sender: mdirector) by mail.iptc.org (Postfix) with ESMTP id D41DB1EFA8A for ; Fri, 6 May 2011 12:29:13 +0200 (CEST) From: "Michael Steidl \(IPTC\)" To: Date: Fri, 6 May 2011 12:29:09 +0200 Organization: IPTC Message-ID: <009001cc0bd8$6f84d700$4e8e8500$@org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0091_01CC0BE9.330DA700" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcwL2G9vFO09js2uQJGbPk3wGEQm5w== Content-Language: de-at X-Greylist: Delayed for 00:26:37 by milter-greylist-4.2.3 (pechora6.dc.icann.org [192.0.46.72]); Fri, 06 May 2011 06:56:12 -0400 (EDT) Subject: [ietf-types] Registration of media type application/vnd.iptc.g2.planningitem+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, 06 May 2011 10:56:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0091_01CC0BE9.330DA700 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: ietf-types@iana.org=20 =20 Subject: Registration of media type application/vnd.iptc.g2.planningitem+xml =20 Media Type Name: application =20 Subtype name: vnd.iptc.g2.planningitem+xml =20 Required parameters: none =20 Optional parameters: charset identical to the charset parameter on application/xml as described in RFC 3023 [RFC3023] section 3.2 =20 Encoding considerations: Identical to those of application/xml as described in RFC 3023, section 3.2 =20 Security considerations: In regards to general XML Security issues, identical to those of "application/xml" as described in RFC3023, section 10. Beyond these general XML Security issues, the media type does not contain active or executable content. The information contained in the media type does not require privacy or integrity services, however the media type does support the use of the XML syntax and processing rules for creating and representing digital signatures as described by RFC3275. =20 Interoperability considerations: =20 Published specification: =20 for NewsML-G2 version 2.7 specifications and EventsML-G2 version 1.6 = specifications =20 http://www.iptc.org/std/NAR/1.8/specification/NAR_1.8-spec-PlanningItem-C= ore.xsd =20 Or =20 http://www.iptc.org/std/NAR/1.8/specification/NAR_1.8-spec-PlanningItem-P= ower.xsd =20 Applications which use this media type: none =20 Additional information: =20 Magic number(s): none =20 File extension(s): .xml =20 Macintosh File Type Code(s): Identical to those of "application/xml" as described in RFC3023, "TEXT" =20 Object Identifier(s) or OID(s): It must be possible to positively identify an Item as it moves through the news workflow, and is transferred from place to place and from system to system. An Item therefore gets a globally unique identifier (guid), which is a persistent, universally unique identifier, and a version which is incremented when the content of the Item is updated. The first version is numbered 1: if the version is not explicitly set, this value must be assumed by the recipient of the Item. The guid is required to be in the form of a IRI. Any IRI capable of acting as a globally unique identifier is accepted; the IPTC provides a standard for this purpose in the form of an IETF RFC [RFC-3085]. =20 Intended usage: =20 A Planning Item conveys information for the editorial staff of media companies about the planned coverage of events or topics=20 by a news provider. Typically a Planning Item holds details like the headline, keywords and the time of release for a set of planned News Items, Concept Items or Package items. Further a Planning Item may provide a list of already delivered Items. =20 Other Information/General Comment: none =20 Person to contact for further information: Name: Michael Steidl E-mail: mdirector@iptc.org =20 Author/Change controller: Name: Michael Steidl E-mail: mdirector@iptc.org =20 -----------------------------=20 =20 Michael Steidl Managing Director of the IPTC [mdirector@iptc.org] International Press Telecommunications Council=20 Web: www.iptc.org - on Twitter = @IPTC Business office address:=20 20 Garrick Street, London WC2E 9BT, United Kingdom Registered in England, company no 101096 =20 ------=_NextPart_000_0091_01CC0BE9.330DA700 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

To: ietf-types@iana.org

 

Subject:

Registration of media type = application/vnd.iptc.g2.planningitem+xml

 

Media Type Name: = application

 

Subtype name: = vnd.iptc.g2.planningitem+xml

 

Required parameters: = none

 

Optional parameters: charset

identical to the charset parameter = on application/xml as described

in RFC 3023 [RFC3023] section = 3.2

 

Encoding considerations: Identical to those of = application/xml as

described in RFC 3023, section 3.2

 

Security considerations: In regards = to general XML Security issues,

identical to those of = "application/xml" as described in = RFC3023,

section 10. Beyond these general XML Security issues, the = media

type = does not contain active or executable content. The = information

contained in the media type does not require privacy or = integrity

services, however the media type does support the use of = the XML

syntax and processing rules for creating and representing = digital

signatures as described by RFC3275.

 

Interoperability = considerations:

 

Published specification:

 

for NewsML-G2 version 2.7 = specifications and EventsML-G2 version 1.6 = specifications

 

http://www.iptc.org/std/NAR/1.8/specification/NAR_1.8-spec-P= lanningItem-Core.xsd

 

Or

 

http://www.iptc.org/std/NAR/1.8/specification/NAR_1.8-spec-P= lanningItem-Power.xsd

 

Applications which use this media type: = none

 

Additional information:

 

Magic number(s): = none

 

File = extension(s): .xml

 

Macintosh File Type Code(s): Identical to those = of

"application/xml" as described in RFC3023, = "TEXT"

 

Object Identifier(s) or OID(s):

It must be possible to positively = identify an Item as it moves

through the news workflow, and is = transferred from place to place

and from system to system. An Item = therefore gets a globally

unique identifier (guid), which is = a persistent, universally unique

identifier, and a version which is = incremented when the content of

the Item is updated. The first = version is numbered 1: if the version

is not explicitly set, this value = must be assumed by the recipient of

the Item. The guid is required to = be in the form of a IRI. Any IRI

capable of acting as a globally = unique identifier is accepted; the

IPTC provides a standard for this = purpose in the form of an IETF RFC

[RFC-3085].

 

Intended = usage:

 

A Planning Item conveys information for the editorial staff = of

media = companies about the planned coverage of events or topics =

by a news = provider.

Typically a Planning Item holds details like the = headline,

keywords and the time of release for a set of planned News = Items,

Concept Items or Package items. Further a Planning = Item

may = provide a list of already delivered Items.

 

Other Information/General Comment: = none

 

Person to contact for further = information:

Name: Michael = Steidl

E-mail: = mdirector@iptc.org

 

Author/Change controller:

Name: Michael = Steidl

E-mail: mdirector@iptc.org

<= p class=3DMsoNormal> 

-----------------------------

 

Michael Steidl

Managing Director of the IPTC = [mdirector@iptc.org]

International Press Telecommunications Council
Web: www.iptc.org - on Twitter @IPTC

Business office address:

20 Garrick Street, London WC2E 9BT, United = Kingdom

Registered in England, company no 101096

 

------=_NextPart_000_0091_01CC0BE9.330DA700-- 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 8B4D8E06D6 for ; Thu, 5 May 2011 15:47:35 -0700 (PDT) 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 ZXDKAQWydEsZ for ; Thu, 5 May 2011 15:47:34 -0700 (PDT) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:1::39]) by ietfa.amsl.com (Postfix) with ESMTP id 1F703E06B5 for ; Thu, 5 May 2011 15:47:33 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id p45MlCET010966 for ; Thu, 5 May 2011 15:47:32 -0700 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 5 May 2011 15:47:12 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 5 May 2011 15:47:11 -0700 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.83]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Thu, 5 May 2011 15:47:11 -0700 From: Brian Clubb To: Pete Resnick , "ietf-types@iana.org" Thread-Topic: [ietf-types] Registration of application/oxps MIME type (Was: Request for final approval for OpenXPS MIME type) Thread-Index: AQHMA2fuEKYp7Fi+3ES1rPxcsPD0qpR/WOkA//+NBLU= Date: Thu, 5 May 2011 22:47:11 +0000 Message-ID: References: <4DB5A49A.8020901@qualcomm.com>,<4DC326F4.5040803@qualcomm.com> In-Reply-To: <4DC326F4.5040803@qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [208.77.188.39]); Thu, 05 May 2011 15:47:32 -0700 (PDT) Subject: Re: [ietf-types] Registration of application/oxps MIME type (Was: Request for final approval for OpenXPS MIME type) X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 22:47:35 -0000 Please do. Definitely a copy/paste mistake between iterations. Thanks! Brian Sent from my Windows Phone -----Original Message----- From: Pete Resnick Sent: Thursday, May 05, 2011 6:38 PM To: ietf-types@iana.org Cc: Brian Clubb Subject: Re: [ietf-types] Registration of application/oxps MIME type (Was: = Request for final approval for OpenXPS MIME type) On 4/25/11 9:43 AM, Pete Resnick wrote: > Type name: application/oxps > Subtype name: Standards Tree - OpenXPS I assume this needs to be fixed to: Type name: application Subtype name: oxps Correct? pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 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 AB19BE08CC for ; Thu, 5 May 2011 15:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.353 X-Spam-Level: X-Spam-Status: No, score=-4.353 tagged_above=-999 required=5 tests=[AWL=-1.754, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7A-ZTl-m-eX6 for ; Thu, 5 May 2011 15:44:36 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id 127FDE08BD for ; Thu, 5 May 2011 15:44:35 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pechora7.dc.icann.org (8.13.8/8.13.8) with SMTP id p45MiEl4013066 for ; Thu, 5 May 2011 18:44:34 -0400 Received: (qmail invoked by alias); 05 May 2011 22:44:12 -0000 Received: from dslb-094-223-189-018.pools.arcor-ip.net (EHLO HIVE) [94.223.189.18] by mail.gmx.net (mp060) with SMTP; 06 May 2011 00:44:12 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/XTCRMS6rXmHbvFAAwIPn0i3/gDU6h3dLGc7y6Qz ID2pzOM/gci1Lg From: Bjoern Hoehrmann To: Pete Resnick Date: Fri, 06 May 2011 00:44:18 +0200 Message-ID: References: <4DB5A49A.8020901@qualcomm.com> <4DC326F4.5040803@qualcomm.com> In-Reply-To: <4DC326F4.5040803@qualcomm.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]); Thu, 05 May 2011 18:44:35 -0400 (EDT) Cc: "ietf-types@iana.org" , Brian Clubb Subject: Re: [ietf-types] Registration of application/oxps MIME type (Was: Request for final approval for OpenXPS MIME type) X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 22:44:37 -0000 * Pete Resnick wrote: >On 4/25/11 9:43 AM, Pete Resnick wrote: >> Type name: application/oxps >> Subtype name: Standards Tree - OpenXPS > >I assume this needs to be fixed to: > >Type name: application >Subtype name: oxps > >Correct? Well, in my capacity as random person posting to this list every now and then, I can confirm that, if the idea is to register "application/oxps". -- 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 7AE1FE06C3 for ; Thu, 5 May 2011 15:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.49 X-Spam-Level: X-Spam-Status: No, score=-104.49 tagged_above=-999 required=5 tests=[AWL=-1.891, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chIxJnqcy-RN for ; Thu, 5 May 2011 15:39:26 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [208.77.188.36]) by ietfa.amsl.com (Postfix) with ESMTP id 89862E06B7 for ; Thu, 5 May 2011 15:39:25 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id p45McoFc006335 for ; Thu, 5 May 2011 15:39:10 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1304635150; x=1336171150; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DC326F4.5040803@qualcomm.com>|Date:=20Th u,=205=20May=202011=2015:38:44=20-0700|From:=20Pete=20Res nick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20"ietf-types@iana.org"=20|CC:=20Brian=20Clubb=20|Subject:=20Re:=20[ietf-types]=20Registration=20o f=20application/oxps=20MIME=20type=20(Was:=0D=0A=20Reques t=20for=20final=20approval=20for=20OpenXPS=20MIME=20type) |References:=20<4DB5A49A.8020901@qualcomm.com> |In-Reply-To:=20<4DB5A49A.8020901@qualcomm.com> |Content-Type:=20text/plain=3B=20charset=3D"ISO-8859-1" =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.39.5]; bh=t7fPAuk6M6Dni8krb95jkunMWSQ34Qi2KrCIMYfm9gI=; b=Qrk+FP9uS1LC290RbfgsW/XCZjPXyvsFUqiTkxr8DKYXAySLyHd3oNR/ 4zqMm12fgInwojhJog5QWAEkq0+rfZGNAfJFMTBqWYzDyGclG6ZZZV1l4 +Oy6eV4NKWnH/txDpLaclFOucAo9rBkhpapBGM0uJT570VpSB7TXZ2bGg A=; X-IronPort-AV: E=McAfee;i="5400,1158,6337"; a="89795903" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 05 May 2011 15:38:48 -0700 X-IronPort-AV: E=Sophos;i="4.64,319,1301900400"; d="scan'208";a="48851787" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 05 May 2011 15:38:45 -0700 Received: from macintosh-4-010072018242.wlan.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 5 May 2011 15:38:45 -0700 Message-ID: <4DC326F4.5040803@qualcomm.com> Date: Thu, 5 May 2011 15:38:44 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "ietf-types@iana.org" References: <4DB5A49A.8020901@qualcomm.com> In-Reply-To: <4DB5A49A.8020901@qualcomm.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [208.77.188.36]); Thu, 05 May 2011 15:39:10 -0700 (PDT) Cc: Brian Clubb Subject: Re: [ietf-types] Registration of application/oxps MIME type (Was: Request for final approval for OpenXPS MIME type) X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 22:39:27 -0000 On 4/25/11 9:43 AM, Pete Resnick wrote: > Type name: application/oxps > Subtype name: Standards Tree - OpenXPS I assume this needs to be fixed to: Type name: application Subtype name: oxps Correct? pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 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 C8F58E08C2 for ; Thu, 5 May 2011 12:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.58 X-Spam-Level: X-Spam-Status: No, score=-104.58 tagged_above=-999 required=5 tests=[AWL=-1.982, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 L95RVB-a5YPB for ; Thu, 5 May 2011 12:11:29 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [208.77.188.36]) by ietfa.amsl.com (Postfix) with ESMTP id 244E3E075F for ; Thu, 5 May 2011 12:11:20 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id p45JAibd012598 for ; Thu, 5 May 2011 12:11:04 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1304622665; x=1336158665; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: x-originating-ip; z=Message-ID:=20<4DC2F631.5060409@qualcomm.com>|Date:=20Th u,=205=20May=202011=2012:10:41=20-0700|From:=20Pete=20Res nick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20"ietf-types@iana.org"=20|CC:=20Brian=20Clubb=20|Subject:=20Re:=20[ietf-types]=20Registration=20o f=20application/oxps=20MIME=20type=20(Was:=0D=0A=20Reques t=20for=20final=20approval=20for=20OpenXPS=20MIME=20type) |References:=20<4DB5A49A.8020901@qualcomm.com> |In-Reply-To:=20<4DB5A49A.8020901@qualcomm.com> |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"------------030009070007000707010206" |X-Originating-IP:=20[172.30.39.5]; bh=+51UlxCO9UIk08ZuUyQ5+pH06X7XMQBoEWrmv6P0h4s=; b=qv8R1ACs1+KhtYRnhM0Bsitj9kws2jFcxaaBErPdQhyHXMPmMAswWwFD wSmEMpMor+7DpuviHB0af2iL6OpOWeQtaDuLrPeX5nmZRfKaoWB5ULet7 8yeiqvQZ1nIzXCktfXOhF85/H66RgxbG8nPbdbfB0F5YuZMQKswmLRX8D I=; X-IronPort-AV: E=McAfee;i="5400,1158,6337"; a="89554539" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 05 May 2011 12:10:43 -0700 X-IronPort-AV: E=Sophos;i="4.64,319,1301900400"; d="scan'208,217";a="33207599" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 05 May 2011 12:10:43 -0700 Received: from macintosh-4-010072021177.wlan.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 5 May 2011 12:10:42 -0700 Message-ID: <4DC2F631.5060409@qualcomm.com> Date: Thu, 5 May 2011 12:10:41 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "ietf-types@iana.org" References: <4DB5A49A.8020901@qualcomm.com> In-Reply-To: <4DB5A49A.8020901@qualcomm.com> Content-Type: multipart/alternative; boundary="------------030009070007000707010206" X-Originating-IP: [172.30.39.5] X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [208.77.188.36]); Thu, 05 May 2011 12:11:05 -0700 (PDT) Cc: Brian Clubb Subject: Re: [ietf-types] Registration of application/oxps MIME type (Was: Request for final approval for OpenXPS MIME type) X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 19:11:33 -0000 --------------030009070007000707010206 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hearing no complaints, this will go to the IESG next week. On 4/25/11 9:43 AM, Pete Resnick wrote: > I am re-posting this with a new thread because I would like to get > some confirmation from the list that this is OK. I suspect it is, but > I'm going to postpone bringing before the IESG until the May 12 > telechat to give the list some time to review. > > The proposal is to register application/oxps instead of > application/OpenXPS to better align with the Open XML Paper > Specification. > > pr > > -------- Original Message -------- > Subject: Re: [ietf-types] Request for final approval for OpenXPS > MIME type > Date: Mon, 25 Apr 2011 16:09:20 +0000 > From: Brian Clubb > To: Franklin Tse , Pete Resnick > > CC: 'ietf-types@iana.org' > > > > Franklin, > > The decision is to revert the registration back to application/oxps > and discuss in committee if we wish to also register > application/OpenXPS in the future as a separate registration. I > appreciate you bringing this to our attention. > > I am attaching a final revision of the template and including in the > message below. > > Thanks! > Brian > > > > -----Original Message----- > From: Brian Clubb > Sent: Sunday, April 24, 2011 10:30 PM > To: Franklin Tse > Subject: RE: [ietf-types] Request for final approval for OpenXPS MIME > type > > Franklin, > > Let me check with the working group and reply back. > > Thanks! > Brian > > Sent from my Windows Phone > > -----Original Message----- > From: Franklin Tse > Sent: Sunday, April 24, 2011 9:57 PM > To: Brian Clubb > Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME > type > > > Dear Brian, > > I noticed that Section E.1 of the current Open XML Paper Specification > recommends "application/oxps" as the content type for .oxps documents, > which is different from the content type you are registering. Is it > the decision of the working group? Will interoperability be an issue? > > Thanks, > Franklin > > MIMEReg.txt > > > Type name: application/oxps > > Subtype name: Standards Tree -- OpenXPS > > Required parameters: N/A > > Optional parameters: N/A > > Encoding considerations: binary > > Security considerations: > OpenXPS uses ZIP compression as specified in .ZIP File Format Specification from PKWARE, Inc., version 6.2.0 (2004). ZIP compressed XML requires parsing untrusted XML data and untrusted ZIP data. The consumer is responsible for validating the .zip archive, the XML structure, and the resource content. Per spec, there should be no active content provided as part of the OpenXPS format. The consumer must ensure that no malicious active content is erroneously provided in the OpenXPS document. Valid content is described in the EMCA-388 specification (http://www.ecma-international.org/publications/standards/Ecma-388.htm). Especially take note of section E.3, which describes steps that can be taken to validate the contents of the payload. > > > Interoperability considerations: > application/oxps documents are specified by the XML schemas standardized in ECMA-388. > Applications and drivers currently producing/consuming Microsoft XPS content cannot directly produce/consume OpenXPS. Changes are required to address differences in the two specifications, such as namespace, print ticket usage, use of JPEG XR, etc. > > To ensure interoperability, the clipboard format must be a complete OpenXPS file with .oxps extension. > > Published specification: > The published standard ECMA-388 is available at: > http://www.ecma-international.org/publications/standards/Ecma-388.htm > > Applications that use this media type: > The application/oxps MIME type can be used to identify CSTA XML > (ECMA-388) instance documents. No published applications or print drivers currently use OpenXPS. The intent is for any application or driver that can currently produce/consume Microsoft XPS to also adopt OpenXPS. Examples of such applications would include but are not limited to: Microsoft XPS Viewer, Microsoft XPS Document Writer, Microsoft Internet Explorer 9. > > Additional information: > > Magic number(s): ZIP archive CRC-32: 504b 0304 per http://www.pkware.com/documents/APPNOTE/APPNOTE-6.2.0.txt. Note that is it a requirement of the consumer to ensure that the contents of the ZIP archive is a valid OpenXPS structure. > File extension(s): .oxps > Macintosh file type code(s): not available > > Windows Clipboard Name: "OpenXPS" > Macintosh Uniform Type Identifier: org.ecma.oxps conforms to com.pkware.zip-archive > > Person& email address to contact for further information: > > Ecma International Helpdesk > Rue du Rhone 114 > CH-1204 Geneva > Switzerland > Ecma International Helpdesk > > Intended usage: COMMON > > > Restrictions on usage: N/A > > > Author: The ECMA-388 Standard is developed and maintained by the Ecma Technical Committee TC46. > > Change controller: The ECMA-388 Standard is developed and maintained by the Ecma Technical Committee TC46. > > > > _______________________________________________ > ietf-types mailing list > ietf-types@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-types > -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 --------------030009070007000707010206 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hearing no complaints, this will go to the IESG next week.

On 4/25/11 9:43 AM, Pete Resnick wrote:
I am re-posting this with a new thread because I would like to get some confirmation from the list that this is OK. I suspect it is, but I'm going to postpone bringing before the IESG until the May 12 telechat to give the list some time to review.

The proposal is to register application/oxps instead of application/OpenXPS to better align with the Open XML Paper Specification.

pr

-------- Original Message --------
Subject:     Re: [ietf-types] Request for final approval for OpenXPS MIME type
Date:     Mon, 25 Apr 2011 16:09:20 +0000
From:     Brian Clubb <Brian.Clubb@microsoft.com>
To:     Franklin Tse <peaceable_whale@hotmail.com>, Pete Resnick <presnick@qualcomm.com>
CC:     'ietf-types@iana.org' <ietf-types@iana.org>



Franklin,

The decision is to revert the registration back to application/oxps and discuss in committee if we wish to also register application/OpenXPS in the future as a separate registration.  I appreciate you bringing this to our attention.

I am attaching a final revision of the template and including in the message below.

Thanks!
Brian

<template>
Type name: application/oxps
Subtype name:  Standards Tree - OpenXPS
Required parameters:  N/A
Optional parameters:  N/A
Encoding considerations:  binary

Security considerations:
OpenXPS uses ZIP compression as specified in .ZIP File Format Specification from PKWARE, Inc., version 6.2.0 (2004).  ZIP compressed XML requires parsing untrusted XML data and untrusted ZIP data.  The consumer is responsible for validating the .zip archive, the XML structure, and the resource content.  Per spec, there should be no active content provided as part of the OpenXPS format.  The consumer must ensure that no malicious active content is erroneously provided in the OpenXPS document.  Valid content is described in the EMCA-388 specification (http://www.ecma-international.org/publications/standards/Ecma-388.htm).  Especially take note of section E.3, which describes steps that can be taken to validate the contents of the payload.

Interoperability considerations:
application/oxps documents are specified by the XML schemas standardized in ECMA-388.  Applications and drivers currently producing/consuming Microsoft XPS content cannot directly produce/consume OpenXPS.  Changes are required to address differences in the two specifications, such as namespace, print ticket usage, use of JPEG XR, etc.
To ensure interoperability, the clipboard format must be a complete OpenXPS file with .oxps extension.

Published specification:
The published standard ECMA-388 is available at:
http://www.ecma-international.org/publications/standards/Ecma-388.htm

Applications that use this media type:
The application/oxps MIME type can be used to identify CSTA XML (ECMA-388) instance documents.  No published applications or print drivers currently use OpenXPS.  The intent is for any application or driver that can currently produce/consume Microsoft XPS to also adopt OpenXPS.  Examples of such applications would include but are not limited to:  Microsoft XPS Viewer, Microsoft XPS Document Writer, Microsoft Internet Explorer 9.

Additional information:
  Magic number(s):  see application/zip.  Note that is it a requirement of the consumer to ensure that the contents of the ZIP archive is a valid OpenXPS structure.
  File extension(s): .oxps
  Macintosh file type code(s):  not available

  Windows Clipboard Name: "OpenXPS"
  Macintosh Uniform Type Identifier: org.ecma.oxps conforms to com.pkware.zip-archive

Person & email address to contact for further information:
Ecma International Helpdesk
Rue du Rhone 114
CH-1204 Geneva
Switzerland
Ecma International Helpdesk<helpdesk@ecma-international.org>

Intended usage: COMMON

Restrictions on usage:  N/A

Author:  The ECMA-388 Standard is developed and maintained by the Ecma Technical Committee TC46.

Change controller:  The ECMA-388 Standard is developed and maintained by the Ecma Technical Committee TC46.
</template>

-----Original Message-----
From: Brian Clubb
Sent: Sunday, April 24, 2011 10:30 PM
To: Franklin Tse
Subject: RE: [ietf-types] Request for final approval for OpenXPS MIME type

Franklin,

Let me check with the working group and reply back.

Thanks!
Brian

Sent from my Windows Phone

-----Original Message-----
From: Franklin Tse
Sent: Sunday, April 24, 2011 9:57 PM
To: Brian Clubb
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME type


Dear Brian,

I noticed that Section E.1 of the current Open XML Paper Specification recommends "application/oxps" as the content type for .oxps documents, which is different from the content type you are registering. Is it the decision of the working group? Will interoperability be an issue?

Thanks,
Franklin 

MIMEReg.txt

Type name: application/oxps

Subtype name:  Standards Tree – OpenXPS

Required parameters:  N/A

Optional parameters:  N/A

Encoding considerations:  binary

Security considerations:
OpenXPS uses ZIP compression as specified in .ZIP File Format Specification from PKWARE, Inc., version 6.2.0 (2004).  ZIP compressed XML requires parsing untrusted XML data and untrusted ZIP data.  The consumer is responsible for validating the .zip archive, the XML structure, and the resource content.  Per spec, there should be no active content provided as part of the OpenXPS format.  The consumer must ensure that no malicious active content is erroneously provided in the OpenXPS document.  Valid content is described in the EMCA-388 specification (http://www.ecma-international.org/publications/standards/Ecma-388.htm).  Especially take note of section E.3, which describes steps that can be taken to validate the contents of the payload.


Interoperability considerations:
application/oxps documents are specified by the XML schemas standardized in ECMA-388.
Applications and drivers currently producing/consuming Microsoft XPS content cannot directly produce/consume OpenXPS.  Changes are required to address differences in the two specifications, such as namespace, print ticket usage, use of JPEG XR, etc.

To ensure interoperability, the clipboard format must be a complete OpenXPS file with .oxps extension.

Published specification:
The published standard ECMA-388 is available at:
http://www.ecma-international.org/publications/standards/Ecma-388.htm

Applications that use this media type:
The application/oxps MIME type can be used to identify CSTA XML
(ECMA-388) instance documents.  No published applications or print drivers currently use OpenXPS.  The intent is for any application or driver that can currently produce/consume Microsoft XPS to also adopt OpenXPS.  Examples of such applications would include but are not limited to:  Microsoft XPS Viewer, Microsoft XPS Document Writer, Microsoft Internet Explorer 9.

Additional information:

  Magic number(s):  ZIP archive CRC-32: 504b 0304 per http://www.pkware.com/documents/APPNOTE/APPNOTE-6.2.0.txt.  Note that is it a requirement of the consumer to ensure that the contents of the ZIP archive is a valid OpenXPS structure.
  File extension(s): .oxps
  Macintosh file type code(s):  not available
	
  Windows Clipboard Name: "OpenXPS"
  Macintosh Uniform Type Identifier: org.ecma.oxps conforms to com.pkware.zip-archive

Person & email address to contact for further information:

Ecma International Helpdesk
Rue du Rhone 114
CH-1204 Geneva
Switzerland
Ecma International Helpdesk<helpdesk@ecma-international.org>

Intended usage: COMMON


Restrictions on usage:  N/A


Author:  The ECMA-388 Standard is developed and maintained by the Ecma Technical Committee TC46.

Change controller:  The ECMA-388 Standard is developed and maintained by the Ecma Technical Committee TC46.
  

_______________________________________________
ietf-types mailing list
ietf-types@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-types
  


-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
--------------030009070007000707010206--