Subject: Re: [ietf-types] [payload] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes.
From: Colin Perkins <[email-masked]>
To: Martin J. Dürst <[email-masked]>
Cc: 'Pete Resnick' <[email-masked]>, [email-masked], [email-masked], [email-masked]
Date: Sun, 29 May 2011 12:37:19 +0100
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>

On 23 May 2011, at 08:55, Martin J. Dürst wrote:
> 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.

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.
> 
> 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:[email-masked]]
>>> Sent: Saturday, May 21, 2011 9:46 AM
>>> To: Roni Even
>>> Cc: 'Pete Resnick'; [email-masked]; ietf-
>>> [email-masked]; 'Ali C. Begen (abegen)'; [email-masked]
>>> 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:[email-masked]]
>>>> Sent: Friday, May 20, 2011 9:56 PM
>>>> To: Roni Even
>>>> Cc: [email-masked]; 'Ali C. Begen (abegen)';
>>>> [email-masked]; [email-masked]
>>>> 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
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ietf-types
>> 
>> 
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

-- 
Colin Perkins
http://csperkins.org/

From: Bjoern Hoehrmann <[email-masked]>
To: Cullen Jennings <[email-masked]>
Date: Sat, 28 May 2011 11:16:20 +0200
Cc: [email-masked], P2PSIP Mailing List <[email-masked]>
Subject: Re: [ietf-types] Registration of media type application/p2p-overlay+xml

* Cullen Jennings wrote:
>   To:  [email-masked]
>
>   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:[email-masked] · 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/ 

From: Cullen Jennings <[email-masked]>
Date: Fri, 27 May 2011 21:40:06 -0600
To: [email-masked]
Cc: P2PSIP Mailing List <[email-masked]>
Subject: [ietf-types] Registration of media type application/p2p-overlay+xml

The draft-ietf-p2psip-base-15 contains the following MINE Type registration. It would appreciate any comments people wanted to send. Thank you

   To:  [email-masked]

   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 <[email-masked]>

   Intended usage:  COMMON

   Restrictions on usage:  None

   Author:  Cullen Jennings <[email-masked]>

   Change controller:  IESG

From: Bjoern Hoehrmann <[email-masked]>
To: Tim Brody <[email-masked]>
Date: Fri, 27 May 2011 15:20:54 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Vendor registration: 'eprints.data+xml'

* 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:[email-masked] · 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/ 

From: Tim Brody <[email-masked]>
To: [email-masked]
Date: Fri, 27 May 2011 14:03:02 +0100
Subject: [ietf-types] Vendor registration: 'eprints.data+xml'

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 <[email-masked]>

Date: Mon, 23 May 2011 16:37:38 +0300
From: Roni Even <[email-masked]>
To: "=?ISO-8859-1?Q?'"Martin_J._Dürst"'?=" <[email-masked]>
Cc: 'Pete Resnick' <[email-masked]>, "'Ali C. Begen \(abegen\)'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM"	and	"MP4V-ES" media sutypes.

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ürst" [mailto:[email-masked]]
> Sent: Monday, May 23, 2011 10:55 AM
> To: Roni Even
> Cc: 'Pete Resnick'; [email-masked]; ietf-
> [email-masked]; 'Ali C. Begen (abegen)'; [email-masked]
> Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and
> "MP4V-ES" media sutypes.
> 
> 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:[email-masked]]
> >> Sent: Saturday, May 21, 2011 9:46 AM
> >> To: Roni Even
> >> Cc: 'Pete Resnick'; [email-masked];
> ietf-
> >> [email-masked]; 'Ali C. Begen (abegen)'; [email-masked]
> >> 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:[email-masked]]
> >>> Sent: Friday, May 20, 2011 9:56 PM
> >>> To: Roni Even
> >>> Cc: [email-masked]; 'Ali C. Begen (abegen)';
> >>> [email-masked]; [email-masked]
> >>> 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
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/ietf-types
> >
> >

Date: Mon, 23 May 2011 16:55:10 +0900
From: =?ISO-8859-1?Q?"Martin_J._Dürst"?= <[email-masked]>
Organization: Aoyama Gakuin University
To: Roni Even <[email-masked]>
Cc: 'Pete Resnick' <[email-masked]>, "'Ali C. Begen \(abegen\)'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM"	and	"MP4V-ES" media sutypes.

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:[email-masked]]
>> Sent: Saturday, May 21, 2011 9:46 AM
>> To: Roni Even
>> Cc: 'Pete Resnick'; [email-masked]; ietf-
>> [email-masked]; 'Ali C. Begen (abegen)'; [email-masked]
>> 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:[email-masked]]
>>> Sent: Friday, May 20, 2011 9:56 PM
>>> To: Roni Even
>>> Cc: [email-masked]; 'Ali C. Begen (abegen)';
>>> [email-masked]; [email-masked]
>>> 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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ietf-types
>
>

Date: Sat, 21 May 2011 10:25:42 +0300
From: Roni Even <[email-masked]>
To: "=?iso-8859-1?Q?'"Martin_J._Dürst"'?=" <[email-masked]>
Cc: 'Pete Resnick' <[email-masked]>, "'Ali C. Begen \(abegen\)'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM"	and	"MP4V-ES" media sutypes.

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:[email-masked]]
> Sent: Saturday, May 21, 2011 9:46 AM
> To: Roni Even
> Cc: 'Pete Resnick'; [email-masked]; ietf-
> [email-masked]; 'Ali C. Begen (abegen)'; [email-masked]
> 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:[email-masked]]
> > Sent: Friday, May 20, 2011 9:56 PM
> > To: Roni Even
> > Cc: [email-masked]; 'Ali C. Begen (abegen)';
> > [email-masked]; [email-masked]
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ietf-types

Date: Sat, 21 May 2011 15:46:22 +0900
From: =?ISO-8859-1?Q?"Martin_J._Dürst"?= <[email-masked]>
Organization: Aoyama Gakuin University
To: Roni Even <[email-masked]>
Cc: 'Pete Resnick' <[email-masked]>, "'Ali C. Begen \(abegen\)'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
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:[email-masked]]
> Sent: Friday, May 20, 2011 9:56 PM
> To: Roni Even
> Cc: [email-masked]; 'Ali C. Begen (abegen)';
> [email-masked]; [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

Date: Sat, 21 May 2011 01:59:35 +0300
From: Roni Even <[email-masked]>
To: "'Pete Resnick'" <[email-masked]>
Cc: [email-masked], [email-masked], "'Ali C. Begen \(abegen\)'" <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and	"MP4V-ES" media sutypes.

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:[email-masked]] 
Sent: Friday, May 20, 2011 9:56 PM
To: Roni Even
Cc: [email-masked]; 'Ali C. Begen (abegen)';
[email-masked]; [email-masked]
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  <http://www.qualcomm.com/~presnick/>
<http://www.qualcomm.com/~presnick/>
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

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;
	color:black;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	color:black;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>Pete,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>This is what we have been doing for all payload specifications. We point at the sections with the registration templates.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Regards<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Roni<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p>&nbsp;</o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> Pete Resnick!
  [mailto:
r><b>Sent:</b> Friday, May 20, 2011 9:56 PM<br><b>To:</b> Roni Even<br><b>Cc:</b> [email-masked]; 'Ali C. Begen (abegen)'; [email-masked]; [email-masked]<br><b>Subject:</b> Re: [ietf-types] updating the registeration of &quot;MP4A-LATM&quot; and &quot;MP4V-ES&quot; media sutypes.<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>On 4/28/11 3:30 AM, Roni Even wrote:<br><br><br><o:p></o:p></p><p class=MsoNormal>draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in the AVT Working Group (currently Payload). The document updates the media subtypes &quot;MP4A-LATM&quot; and &quot;MP4V-ES&quot;&nbsp; from RFC 3016.&nbsp; The new registrations are in Section 6.1 and&nbsp;&nbsp; Section 6.3 of the document.<o:p></o:p></p><p class=MsoNormal>Comments on the registration are welcome.<o:p></o:p></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'><br>Roni, !
 it would 
ed the registration templates themselves instead of pointing to the draft.<br><br>Thanks,<br><br>pr<br><br><o:p></o:p></span></p><pre>-- <o:p></o:p></pre><pre>Pete Resnick <a href="http://www.qualcomm.com/~presnick/">&lt;http://www.qualcomm.com/~presnick/&gt;</a><o:p></o:p></pre><pre>Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102<o:p></o:p></pre></div></div></body></html>

--Boundary_(ID_+UVEk8Fuqhw1eG5b0jMSGQ)--

Date: Fri, 20 May 2011 13:55:51 -0500
From: Pete Resnick <[email-masked]>
To: Roni Even <[email-masked]>
Cc: [email-masked], [email-masked], "'Ali C. Begen \(abegen\)'" <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and	"MP4V-ES" media sutypes.

--------------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<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

--------------000702020106030703020000
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 4/28/11 3:30 AM, Roni Even wrote:<br>
<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <meta http-equiv="Content-Type"
 content="text/html; charset=ISO-8859-1">
  <meta name="Generator" content="Microsoft Word 12 (filtered medium)">
  <style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
  <div class="WordSection1">
  <p class="MsoNormal"><o:p></o:p>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"&nbsp; from RFC 3016.&nbsp; The new registrations are in Section 6.1
and&nbsp;&nbsp; Section 6.3 of the document.<o:p></o:p></p>
  <p class="MsoNormal">Comments on the registration are welcome.<o:p></o:p></p>
  </div>
</blockquote>
<br>
Roni, it would probably help if you posted the registration templates
themselves instead of pointing to the draft.<br>
<br>
Thanks,<br>
<br>
pr<br>
<pre class="moz-signature" cols="72">-- 
Pete Resnick <a class="moz-txt-link-rfc2396E" href="http://www.qualcomm.com/~presnick/">&lt;http://www.qualcomm.com/~presnick/&gt;</a>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102</pre>
</body>
</html>

--------------000702020106030703020000--

Date: Thu, 19 May 2011 13:52:09 -0400 (EDT)
From: Robin Cover <[email-masked]>
To: "Media (MIME) Type Review List" <[email-masked]>
Cc: Drummond Reed <[email-masked]>, "Media \(MIME\) Type Review List" <[email-masked]>, Bjoern Hoehrmann <[email-masked]>
Subject: Re: [ietf-types] Registration of media type xrd+xml

  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: [email-masked]
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?
> -- 
> Björn Höhrmann · mailto:[email-masked] · 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/
>
--8323329-1492452631-1305827529=:7188--

From: Bjoern Hoehrmann <[email-masked]>
To: Robin Cover <[email-masked]>
Date: Thu, 19 May 2011 17:13:48 +0200
Cc: "Media \(MIME\) Type Review List" <[email-masked]>, Drummond Reed <[email-masked]>
Subject: Re: [ietf-types] Registration of media type xrd+xml

* 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:[email-masked] · 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/ 

Date: Thu, 19 May 2011 10:41:58 -0400 (EDT)
From: Robin Cover <[email-masked]>
To: "Media (MIME) Type Review List" <[email-masked]>
Cc: Drummond Reed <[email-masked]>
Subject: [ietf-types] Registration of media type xrd+xml

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 <[email-masked]>
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: [email-masked]
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

From: Paul Libbrecht <[email-masked]>
Date: Tue, 17 May 2011 09:22:31 +0200
To: Michael Steidl (IPTC) <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Registration of media type application/vnd.iptc.g2.planningitem+xml

--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 à 12:29, Michael Steidl (IPTC) a écrit :

> To: [email-masked]
>  
> 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-PlanningItem-Core.xsd
>  
> Or
>  
> http://www.iptc.org/std/NAR/1.8/specification/NAR_1.8-spec-PlanningItem-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: [email-masked]
>  
> Author/Change controller:
> Name: Michael Steidl
> E-mail: [email-masked]
>  
> -----------------------------
>  
> Michael Steidl
> Managing Director of the IPTC [[email-masked]]
> 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
>  
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> 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

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Michael,</div><div><br></div><div>I would like to suggest to add the following two lines in the "Additional information" section:</div><div><br></div><div>- Windows Clipboard Flavor Name: "IPTC Planningitem XML"</div><div>- Macintosh Uniform Type Identifier: org.iptc.planningitem&nbsp;conforms to public.xml</div><div><br></div><div>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.</div><div><br></div><div>paul</div><div><br></div><br><div><div>Le 6 mai 2011 à 12:29, Michael Steidl (IPTC) a écrit :</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div lang="DE-AT" link="blue" vlink="purple"><div class="WordSection1"><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">To:<span class="Apple-converted-space">&nbsp;</span><a href="mailto:[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Subject:<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Registration of media type application/vnd.iptc.g2.planningitem+xml<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Media Type Name: application<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Subtype name: vnd.iptc.g2.planningitem+xml<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Required parameters: none<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Optional parameters: charset<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">identical to the charset parameter on application/xml as described<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">in RFC 3023 [RFC3023] section 3.2<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Encoding considerations: Identical to those of application/xml as<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">described in RFC 3023, section 3.2<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Security considerations: In regards to general XML Security issues,<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">identical to those of "application/xml" as described in RFC3023,<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">section 10. Beyond these general XML Security issues, the media<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">type does not contain active or executable content. The information<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">contained in the media type does not require privacy or integrity<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">services, however the media type does support the use of the XML<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">syntax and processing rules for creating and representing digital<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">signatures as described by RFC3275.<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Interoperability considerations:<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Published specification:<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">for NewsML-G2 version 2.7 specifications and EventsML-G2 version 1.6 specifications<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><a href="http://www.iptc.org/std/NAR/1.8/specification/NAR_1.8-spec-PlanningItem-Core.xsd" style="color: blue; text-decoration: underline; ">http://www.iptc.org/std/NAR/1.8/specification/NAR_1.8-spec-PlanningItem-Core.xsd</a><o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Or<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><a href="http://www.iptc.org/std/NAR/1.8/specification/NAR_1.8-spec-PlanningItem-Power.xsd" style="color: blue; text-decoration: underline; ">http://www.iptc.org/std/NAR/1.8/specification/NAR_1.8-spec-PlanningItem-Power.xsd</a><o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Applications which use this media type: none<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Additional information:<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Magic number(s): none<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; ">File extension(s): .xml<o:p></o:p></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Macintosh File Type Code(s): Identical to those of<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">"application/xml" as described in RFC3023, "TEXT"<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Object Identifier(s) or OID(s):<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">It must be possible to positively identify an Item as it moves<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">through the news workflow, and is transferred from place to place<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">and from system to system. An Item therefore gets a globally<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">unique identifier (guid), which is a persistent, universally unique<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">identifier, and a version which is incremented when the content of<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">the Item is updated. The first version is numbered 1: if the version<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">is not explicitly set, this value must be assumed by the recipient of<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">the Item. The guid is required to be in the form of a IRI. Any IRI<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">capable of acting as a globally unique identifier is accepted; the<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">IPTC provides a standard for this purpose in the form of an IETF RFC<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">[RFC-3085].<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Intended usage:<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">A Planning Item conveys information for the editorial staff of<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">media companies about the planned coverage of events or topics<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">by a news provider.<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Typically a Planning Item holds details like the headline,<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">keywords and the time of release for a set of planned News Items,<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Concept Items or Package items. Further a Planning Item<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">may provide a list of already delivered Items.<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Other Information/General Comment: none<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Person to contact for further information:<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; ">Name: Michael Steidl<o:p></o:p></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; ">E-mail:<span class="Apple-converted-space">&nbsp;</span><a href="mailto:[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><o:p></o:p></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Author/Change controller:<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB">Name: Michael Steidl<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; ">E-mail:<span class="Apple-converted-space">&nbsp;</span><a href="mailto:[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><o:p></o:p></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; ">-----------------------------<o:p></o:p></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><b><span style="font-size: 10pt; font-family: Arial, sans-serif; color: rgb(31, 73, 125); ">Michael Steidl<o:p></o:p></span></b></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB" style="font-size: 10pt; font-family: Arial, sans-serif; color: rgb(31, 73, 125); ">Managing Director of the IPTC [[email-masked]]<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB" style="font-size: 10pt; font-family: Arial, sans-serif; color: rgb(31, 73, 125); ">International Press Telecommunications Council<span class="Apple-converted-space">&nbsp;</span><br>Web:<span class="Apple-converted-space">&nbsp;</span></span><span style="font-size: 10pt; font-family: Arial, sans-serif; color: rgb(31, 73, 125); "><a href="http://www.iptc.org/" style="color: blue; text-decoration: underline; "><span lang="EN-GB" style="color: rgb(31, 73, 125); ">www.iptc.org</span></a></span><span lang="EN-GB" style="font-size: 10pt; font-family: Arial, sans-serif; color: rgb(31, 73, 125); "><span class="Apple-converted-space">&nbsp;</span>- on Twitter<span class="Apple-converted-space">&nbsp;</span></span><span style="font-size: 10pt; font-family: Arial, sans-serif; color: rgb(31, 73, 125); "><a href="http://www.twitter.com/IPTC" style="color: blue; text-decoration: underline; "><span lang="EN-GB" style="color: rgb(31, 73, 125); ">@IPTC</span></a></span><span lang="EN-GB" style="font-size: 10pt; font-family: Arial, sans-serif; color: rgb(31, 73, 125); "><o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB" style="font-size: 10pt; font-family: Arial, sans-serif; color: rgb(31, 73, 125); ">Business office address:<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB" style="font-size: 10pt; font-family: Arial, sans-serif; color: rgb(31, 73, 125); ">20 Garrick Street, London WC2E 9BT, United Kingdom<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB" style="font-size: 10pt; font-family: Arial, sans-serif; color: rgb(31, 73, 125); ">Registered in England, company no 101096<o:p></o:p></span></div><div style="margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; margin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; "><span lang="EN-GB"><o:p>&nbsp;</o:p></span></div></div>_______________________________________________<br>ietf-types mailing list<br><a href="mailto:[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><br><a href="https://www.ietf.org/mailman/listinfo/ietf-types" style="color: blue; text-decoration: underline; ">https://www.ietf.org/mailman/listinfo/ietf-types</a><br></div></span></blockquote></div><br></body></html>
--Apple-Mail-14-892237391--

Date: Mon, 16 May 2011 15:29:56 -0500
From: Pete Resnick <[email-masked]>
To: Roni Even <[email-masked]>
Cc: [email-masked], [email-masked], "'Ali C. Begen \(abegen\)'" <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] updating the registeration of "MP4A-LATM" and	"MP4V-ES" media sutypes.

--------------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<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

--------------010600010401050803030103
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Did anyone review this? I have seen no responses.<br>
<br>
pr<br>
<br>
On 4/28/11 3:30 AM, Roni Even wrote:
<blockquote cite="mid:[email-masked]"
 type="cite">
  <meta http-equiv="Content-Type"
 content="text/html; charset=ISO-8859-1">
  <meta name="Generator" content="Microsoft Word 12 (filtered medium)">
  <style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
  <div class="WordSection1">
  <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
  <p class="MsoNormal">Hi,<o:p></o:p></p>
  <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
  <p class="MsoNormal">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"&nbsp; from RFC
3016.&nbsp; The new registrations are in Section 6.1 and&nbsp;&nbsp; Section 6.3 of
the document.<o:p></o:p></p>
  <p class="MsoNormal">Comments on the registration are welcome.<o:p></o:p></p>
  <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
  <p class="MsoNormal">Thanks<o:p></o:p></p>
  <p class="MsoNormal">Roni Even<o:p></o:p></p>
  <p class="MsoNormal">Payload WG co-chair<o:p></o:p></p>
  </div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
Pete Resnick <a class="moz-txt-link-rfc2396E" href="http://www.qualcomm.com/~presnick/">&lt;http://www.qualcomm.com/~presnick/&gt;</a>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102</pre>
</body>
</html>

--------------010600010401050803030103--

From: Peeter Piegaze <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 9 May 2011 14:13:25 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: Pete Resnick <[email-masked]>, David Nuescheler <[email-masked]>
Subject: [ietf-types] Registration of media type text/jcr-cnd

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=283). See especially sections 3.7 and 25.2. 
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=333)

Applications that use this media type: Used by content repositories that implement the
Content Repository For Java API (JCR) 

Additional information:
File extension(s): .cnd

Person & email address to contact for further information:
Peeter Piegaze [email-masked]
David Nuescheler [email-masked]

Intended usage: Common

Restrictions on usage: None

Author: JSR-333 Expert Group

Change controller: Peeter Piegaze [email-masked]

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.

From: Bjoern Hoehrmann <[email-masked]>
To: Julian Reschke <[email-masked]>
Date: Mon, 09 May 2011 23:12:12 +0200
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [ietf-types] Fwd: Request for MIME media type text/jcr-cnd

* 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:[email-masked] · 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/ 

Date: Mon, 09 May 2011 22:38:38 +0200
From: Julian Reschke <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [ietf-types] Fwd: Request for MIME media type text/jcr-cnd

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 <[email-masked]>
To: [email-masked] <[email-masked]>
CC: David Nuescheler <[email-masked]>,        "[email-masked]" 
<[email-masked]>

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(3. 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
[email-masked]

Peeter Piegaze
Adobe Systems
[email-masked]

Date: Mon, 09 May 2011 22:33:37 +0200
From: Julian Reschke <[email-masked]>
To: [email-masked]
Subject: [ietf-types] mail test

From: "Michael Steidl \(IPTC\)" <[email-masked]>
To: <[email-masked]>
Date: Fri, 6 May 2011 12:29:09 +0200
Organization: IPTC
Subject: [ietf-types] Registration of media type application/vnd.iptc.g2.planningitem+xml

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: [email-masked] 

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-PlanningItem-Core.xsd

Or

http://www.iptc.org/std/NAR/1.8/specification/NAR_1.8-spec-PlanningItem-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: [email-masked]

Author/Change controller:

Name: Michael Steidl

E-mail: [email-masked]

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

Michael Steidl

Managing Director of the IPTC [[email-masked]]

International Press Telecommunications Council 
Web:  <http://www.iptc.org/> www.iptc.org - on Twitter  <http://www.twitter.com/IPTC> @IPTC

Business office address: 

20 Garrick Street, London WC2E 9BT, United Kingdom

Registered in England, company no 101096

------=_NextPart_000_0091_01CC0BE9.330DA700
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="&#1;" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.E-MailFormatvorlage17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=DE-AT link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span lang=EN-GB>To: [email-masked] <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>Subject:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Registration of media type application/vnd.iptc.g2.planningitem+xml<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>Media Type Name: application<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>Subtype name: vnd.iptc.g2.planningitem+xml<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>Required parameters: none<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>Optional parameters: charset<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>identical to the charset parameter on application/xml as described<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>in RFC 3023 [RFC3023] section 3.2<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>Encoding considerations: Identical to those of application/xml as<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>described in RFC 3023, section 3.2<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>Security considerations: In regards to general XML Security issues,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>identical to those of &quot;application/xml&quot; as described in RFC3023,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>section 10. Beyond these general XML Security issues, the media<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>type does not contain active or executable content. The information<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>contained in the media type does not require privacy or integrity<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>services, however the media type does support the use of the XML<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>syntax and processing rules for creating and representing digital<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>signatures as described by RFC3275.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>Interoperability considerations:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>Published specification:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>for NewsML-G2 version 2.7 specifications and EventsML-G2 version 1.6 specifications<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>http://www.iptc.org/std/NAR/1.8/specification/NAR_1.8-spec-PlanningItem-Core.xsd<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>Or<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>http://www.iptc.org/std/NAR/1.8/specification/NAR_1.8-spec-PlanningItem-Power.xsd<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>Applications which use this media type: none<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>Additional information:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>Magic number(s): none<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal>File extension(s): .xml<o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal><span lang=EN-GB>Macintosh File Type Code(s): Identical to those of<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>&quot;application/xml&quot; as described in RFC3023, &quot;TEXT&quot;<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>Object Identifier(s) or OID(s):<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>It must be possible to positively identify an Item as it moves<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>through the news workflow, and is transferred from place to place<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>and from system to system. An Item therefore gets a globally<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>unique identifier (guid), which is a persistent, universally unique<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>identifier, and a version which is incremented when the content of<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>the Item is updated. The first version is numbered 1: if the version<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>is not explicitly set, this value must be assumed by the recipient of<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>the Item. The guid is required to be in the form of a IRI. Any IRI<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>capable of acting as a globally unique identifier is accepted; the<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>IPTC provides a standard for this purpose in the form of an IETF RFC<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>[RFC-3085].<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>Intended usage:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>A Planning Item conveys information for the editorial staff of<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>media companies about the planned coverage of events or topics <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>by a news provider.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Typically a Planning Item holds details like the headline,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>keywords and the time of release for a set of planned News Items,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Concept Items or Package items. Further a Planning Item<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>may provide a list of already delivered Items.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>Other Information/General Comment: none<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span lang=EN-GB>Person to contact for further information:<o:p></o:p></span></p><p class=MsoNormal>Name: Michael Steidl<o:p></o:p></p><p class=MsoNormal>E-mail: [email-masked]<o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal><span lang=EN-GB>Author/Change controller:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Name: Michael Steidl<o:p></o:p></span></p><p class=MsoNormal>E-mail: <a href="mailto:[email-masked]">[email-masked]</a><o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>----------------------------- <o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal style='text-autospace:none'><b><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>Michael Steidl<o:p></o:p></span></b></p><p class=MsoNormal style='text-autospace:none'><span lang=EN-GB style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>Managing Director of the IPTC [[email-masked]]<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span lang=EN-GB style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>International Press Telecommunications Council <br>Web: </span><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'><a href="http://www.iptc.org/"><span lang=EN-GB style='color:#1F497D'>www.iptc.org</span></a></span><span lang=EN-GB style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'> - on Twitter </span><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'><a href="http://www.twitter.com/IPTC"><span lang=EN-GB style='color:#1F497D'>@IPTC</span></a></span><span lang=EN-GB style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span lang=EN-GB style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>Business office address: <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span lang=EN-GB style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>20 Garrick Street, London WC2E 9BT, United Kingdom<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span lang=EN-GB style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>Registered in England, company no 101096<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p></div></body></html>
------=_NextPart_000_0091_01CC0BE9.330DA700--

From: Brian Clubb <[email-masked]>
To: Pete Resnick <[email-masked]>, "[email-masked]" <[email-masked]>
Accept-Language: en-US
Subject: Re: [ietf-types] Registration of application/oxps MIME type (Was: Request for final approval for OpenXPS MIME type)

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: [email-masked]
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<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: Bjoern Hoehrmann <[email-masked]>
To: Pete Resnick <[email-masked]>
Date: Fri, 06 May 2011 00:44:18 +0200
Cc: "[email-masked]" <[email-masked]>, Brian Clubb <[email-masked]>
Subject: Re: [ietf-types] Registration of application/oxps MIME type (Was: Request for final approval for OpenXPS MIME type)

* 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:[email-masked] · 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/ 

Date: Thu, 5 May 2011 15:38:44 -0700
From: Pete Resnick <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: Brian Clubb <[email-masked]>
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<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Thu, 5 May 2011 12:10:41 -0700
From: Pete Resnick <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: Brian Clubb <[email-masked]>
Subject: Re: [ietf-types] Registration of application/oxps MIME type (Was: Request for final approval for OpenXPS MIME type)

--------------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 <[email-masked]>
> To:     Franklin Tse <[email-masked]>, Pete Resnick 
> <[email-masked]>
> CC:     [email-masked]' <[email-masked]>
>
>
>
> 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<[email-masked]>
>
> 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<[email-masked]>
>
> 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
> [email-masked]
> 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
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hearing no complaints, this will go to the IESG next week.<br>
<br>
On 4/25/11 9:43 AM, Pete Resnick wrote:
<blockquote cite="mid:[email-masked]" type="cite">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.
  <br>
  <br>
The proposal is to register application/oxps instead of
application/OpenXPS to better align with the Open XML Paper
Specification.
  <br>
  <br>
pr
  <br>
  <br>
-------- Original Message --------
  <br>
Subject:&nbsp;&nbsp;&nbsp;&nbsp; Re: [ietf-types] Request for final approval for OpenXPS
MIME type
  <br>
Date:&nbsp;&nbsp;&nbsp;&nbsp; Mon, 25 Apr 2011 16:09:20 +0000
  <br>
From:&nbsp;&nbsp;&nbsp;&nbsp; Brian Clubb <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
  <br>
To:&nbsp;&nbsp;&nbsp;&nbsp; Franklin Tse <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>, Pete Resnick
<a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
  <br>
CC:&nbsp;&nbsp;&nbsp;&nbsp; '<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>' <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
  <br>
  <br>
  <br>
  <br>
Franklin,
  <br>
  <br>
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.&nbsp; I appreciate you bringing this
to our attention.
  <br>
  <br>
I am attaching a final revision of the template and including in the
message below.
  <br>
  <br>
Thanks!
  <br>
Brian
  <br>
  <br>
&lt;template&gt;
  <br>
Type name: application/oxps
  <br>
Subtype name:&nbsp; Standards Tree - OpenXPS
  <br>
Required parameters:&nbsp; N/A
  <br>
Optional parameters:&nbsp; N/A
  <br>
Encoding considerations:&nbsp; binary
  <br>
  <br>
Security considerations:
  <br>
OpenXPS uses ZIP compression as specified in .ZIP File Format
Specification from PKWARE, Inc., version 6.2.0 (2004).&nbsp; ZIP compressed
XML requires parsing untrusted XML data and untrusted ZIP data.&nbsp; The
consumer is responsible for validating the .zip archive, the XML
structure, and the resource content.&nbsp; Per spec, there should be no
active content provided as part of the OpenXPS format.&nbsp; The consumer
must ensure that no malicious active content is erroneously provided in
the OpenXPS document.&nbsp; Valid content is described in the EMCA-388
specification
(<a class="moz-txt-link-freetext" href="http://www.ecma-international.org/publications/standards/Ecma-388.htm">http://www.ecma-international.org/publications/standards/Ecma-388.htm</a>).&nbsp;
Especially take note of section E.3, which describes steps that can be
taken to validate the contents of the payload.
  <br>
  <br>
Interoperability considerations:
  <br>
application/oxps documents are specified by the XML schemas
standardized in ECMA-388.&nbsp; Applications and drivers currently
producing/consuming Microsoft XPS content cannot directly
produce/consume OpenXPS.&nbsp; Changes are required to address differences
in the two specifications, such as namespace, print ticket usage, use
of JPEG XR, etc.
  <br>
To ensure interoperability, the clipboard format must be a complete
OpenXPS file with .oxps extension.
  <br>
  <br>
Published specification:
  <br>
The published standard ECMA-388 is available at:
  <br>
<a class="moz-txt-link-freetext" href="http://www.ecma-international.org/publications/standards/Ecma-388.htm">http://www.ecma-international.org/publications/standards/Ecma-388.htm</a>
  <br>
  <br>
Applications that use this media type:
  <br>
The application/oxps MIME type can be used to identify CSTA XML
(ECMA-388) instance documents.&nbsp; No published applications or print
drivers currently use OpenXPS.&nbsp; The intent is for any application or
driver that can currently produce/consume Microsoft XPS to also adopt
OpenXPS.&nbsp; Examples of such applications would include but are not
limited to:&nbsp; Microsoft XPS Viewer, Microsoft XPS Document Writer,
Microsoft Internet Explorer 9.
  <br>
  <br>
Additional information:
  <br>
&nbsp; Magic number(s):&nbsp; see application/zip.&nbsp; Note that is it a requirement
of the consumer to ensure that the contents of the ZIP archive is a
valid OpenXPS structure.
  <br>
&nbsp; File extension(s): .oxps
  <br>
&nbsp; Macintosh file type code(s):&nbsp; not available
  <br>
  <br>
&nbsp; Windows Clipboard Name: "OpenXPS"
  <br>
&nbsp; Macintosh Uniform Type Identifier: org.ecma.oxps conforms to
com.pkware.zip-archive
  <br>
  <br>
Person &amp; email address to contact for further information:
  <br>
Ecma International Helpdesk
  <br>
Rue du Rhone 114
  <br>
CH-1204 Geneva
  <br>
Switzerland
  <br>
Ecma International Helpdesk<a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
  <br>
  <br>
Intended usage: COMMON
  <br>
  <br>
Restrictions on usage:&nbsp; N/A
  <br>
  <br>
Author:&nbsp; The ECMA-388 Standard is developed and maintained by the Ecma
Technical Committee TC46.
  <br>
  <br>
Change controller:&nbsp; The ECMA-388 Standard is developed and maintained
by the Ecma Technical Committee TC46.
  <br>
&lt;/template&gt;
  <br>
  <br>
-----Original Message-----
  <br>
From: Brian Clubb
  <br>
Sent: Sunday, April 24, 2011 10:30 PM
  <br>
To: Franklin Tse
  <br>
Subject: RE: [ietf-types] Request for final approval for OpenXPS MIME
type
  <br>
  <br>
Franklin,
  <br>
  <br>
Let me check with the working group and reply back.
  <br>
  <br>
Thanks!
  <br>
Brian
  <br>
  <br>
Sent from my Windows Phone
  <br>
  <br>
-----Original Message-----
  <br>
From: Franklin Tse
  <br>
Sent: Sunday, April 24, 2011 9:57 PM
  <br>
To: Brian Clubb
  <br>
Subject: Re: [ietf-types] Request for final approval for OpenXPS MIME
type
  <br>
  <br>
  <br>
Dear Brian,
  <br>
  <br>
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?
  <br>
  <br>
Thanks,
  <br>
Franklin
  <br>
  <br>
  <pre wrap="">
<fieldset class="mimeAttachmentHeader"><legend
 class="mimeAttachmentName">MIMEReg.txt</legend></fieldset>
Type name: application/oxps

Subtype name:  Standards Tree &#8211; 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 (<a class="moz-txt-link-freetext" href="http://www.ecma-international.org/publications/standards/Ecma-388.htm">http://www.ecma-international.org/publications/standards/Ecma-388.htm</a>).  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:
<a class="moz-txt-link-freetext" href="http://www.ecma-international.org/publications/standards/Ecma-388.htm">http://www.ecma-international.org/publications/standards/Ecma-388.htm</a>

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 <a class="moz-txt-link-freetext" href="http://www.pkware.com/documents/APPNOTE/APPNOTE-6.2.0.txt">http://www.pkware.com/documents/APPNOTE/APPNOTE-6.2.0.txt</a>.  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 &amp; email address to contact for further information:

Ecma International Helpdesk
Rue du Rhone 114
CH-1204 Geneva
Switzerland
Ecma International Helpdesk<a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>

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.
  </pre>
  <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
ietf-types mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/ietf-types">https://www.ietf.org/mailman/listinfo/ietf-types</a>
  </pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">-- 
Pete Resnick <a class="moz-txt-link-rfc2396E" href="http://www.qualcomm.com/~presnick/">&lt;http://www.qualcomm.com/~presnick/&gt;</a>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102</pre>
</body>
</html>

--------------030009070007000707010206--