Sean Leonard | 11 Sep 05:48 2014

Standardizing on application/tar for tar files

Hello,

Suppose that it is desirable to standardize on application/tar for .tar 
files <https://en.wikipedia.org/wiki/Tar_(computing)>.

Tar is standardized in POSIX.1-2001, which is both IEEE 1003 and ISO/IEC 
9945. The standard description in the pax topic 
<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html> is 
complete. However, there is no IANA registration template in POSIX.

What is the recommended way to register this media type, if I wanted to 
just go ahead and do it with a minimum of fuss (but maximizing quality 
of the registration)?

Thanks,

Sean
mike amundsen | 2 Sep 19:12 2014
Picon

Fwd: New Version Notification for draft-amundsen-richardson-foster-alps-00.txt

Greetings:

I've started an I-D for the ALPS (Application-Level Profile Semantics) media type (see below).

This is an early draft and we're looking forward to feedback and suggestions.

Cheers.




---------- Forwarded message ----------
From: <internet-drafts <at> ietf.org>
Date: Tue, Sep 2, 2014 at 12:56 PM
Subject: New Version Notification for draft-amundsen-richardson-foster-alps-00.txt
To: Mike Amundsen <mca <at> amundsen.com>, Leonard Richardson <leonardr <at> segfault.org>, "Mark W. Foster" <mwf <at> fosrias.com>



A new version of I-D, draft-amundsen-richardson-foster-alps-00.txt
has been successfully submitted by Mike Amundsen and posted to the
IETF repository.

Name:           draft-amundsen-richardson-foster-alps
Revision:       00
Title:          Application-Level Profile Semantics (ALPS)
Document date:  2014-09-02
Group:          Individual Submission
Pages:          27
URL:            http://www.ietf.org/internet-drafts/draft-amundsen-richardson-foster-alps-00.txt
Status:         https://datatracker.ietf.org/doc/draft-amundsen-richardson-foster-alps/
Htmlized:       http://tools.ietf.org/html/draft-amundsen-richardson-foster-alps-00


Abstract:
   This document describes ALPS, a data format for defining simple
   descriptions of application-level semantics, similar in complexity to
   HTML microformats.  An ALPS document can be used as a profile to
   explain the application semantics of a document with an application-
   agnostic media type (such as HTML, HAL, Collection+JSON, Siren,
   etc.).  This increases the reusability of profile documents across
   media types.

Editorial Note (To be removed by RFC Editor)

   Distribution of this document is unlimited.  Comments should be sent
   to the IETF Media-Types mailing list (see [1]).




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Roni Even | 29 Aug 11:52 2014
Picon

registeration of H265 media subtype for High Efficiency Video Coding (H.265) payload format

Hi,

draft-ietf-payload-rtp-h265-04  is in Working Group Last Call in the Payload Working Group.

The document registers media subtype H265. 

 

The new registrations are in Section 7.1 of the document and is also given bellow.

 

Comments on the registration are welcome.

 

Thanks

Roni Even

Payload WG co-chair

 

Media Type name:     video

 

   Media subtype name:  H265

 

   Required parameters: none

 

   OPTIONAL parameters:

 

      profile-space, tier-flag, profile-id, profile-compatibility-

      indicator, interop-constraints, and level-id:

 

         These parameters indicate the profile, tier, default level,

         and some constraints of the bitstream carried by the RTP

         stream and all RTP streams the RTP stream depends on, or a

         specific set of the profile, tier, default level, and some

         constraints the receiver supports.

 

         The profile and some constraints are indicated collectively by

         profile-space, profile-id, profile-compatibility-indicator,

         and interop-constraints.  The profile specifies the subset of

         coding tools that may have been used to generate the bitstream

         or that the receiver supports.

 

            Informative note: There are 32 values of profile-id, and

            there are 32 flags in profile-compatibility-indicator, each

            flag corresponding to one value of profile-id.  According

            to HEVC version 1 in [HEVC], when more than one of the 32

            flags is set for a bitstream, the bitstream would comply

            with all the profiles corresponding to the set flags.

            However, in a draft of HEVC version 2 in [HEVC draft v2],

            subclause A.3.5, 19 Format Range Extensions profiles have

            been specified, all using the same value of profile-id (4),

            differentiated by some of the 48 bits in interop-

            constraints - this (rather unexpected way of profile

            signalling) means that one of the 32 flags may correspond

            to multiple profiles.  To be able to support whatever HEVC

            extension profile that might be specified and indicated

            using profile-space, profile-id, profile-compatibility-

            indicator, and interop-constraints in the future, it would

            be safe to require symmetric use of these parameters in SDP

            offer/answer unless recv-sub-layer-id is included in the

            SDP answer for choosing one of the sub-layers offered.

 

         The tier is indicated by tier-flag.  The default level is

         indicated by level-id.  The tier and the default level specify

         the limits on values of syntax elements or arithmetic

         combinations of values of syntax elements that are followed

         when generating the bitstream or that the receiver supports.

 

         A set of profile-space, tier-flag, profile-id, profile-

         compatibility-indicator, interop-constraints, and level-id

         parameters ptlA is said to be consistent with another set of

         these parameters ptlB if any decoder that conforms to the

         profile, tier, level, and constraints indicated by ptlB can

         decode any bitstream that conforms to the profile, tier,

         level, and constraints indicated by ptlA.

 

         In SDP offer/answer, when the SDP answer does not include the

         recv-sub-layer-id parameter that is less than the sprop-sub-

         layer-id parameter in the SDP offer, the following applies:

 

            o The profile-space, tier-flag, profile-id, profile-

              compatibility-indicator, and interop-constraints

              parameters MUST be used symmetrically, i.e. the value of

              each of these parameters in the offer MUST be the same as

              that in the answer, either explicitly signalled or

              implicitly inferred.

            o The level-id parameter is changeable as long as the

              highest level indicated by the answer is either equal to

              or lower than that in the offer.  Note that the highest

              level is indicated by level-id and max-recv-level-id

              together.

 

         In SDP offer/answer, when the SDP answer does include the

         recv-sub-layer-id parameter that is less than the sprop-sub-

         layer-id parameter in the SDP offer, the set of profile-space,

         tier-flag, profile-id, profile-compatibility-indicator,

         interop-constraints, and level-id parameters included in the

         answer MUST be consistent with that for the chosen sub-layer

         representation as indicated in the SDP offer, with the

         exception that the level-id parameter in the SDP answer is

         changable as long as the highest level indicated by the answer

         is either lower than or equal to that in the offer.

 

         More specifications of these parameters, including how they

         relate to the values of the profile, tier, and level syntax

         elements specified in [HEVC] are provided below.

 

      profile-space, profile-id:

 

         The value of profile-space MUST be in the range of 0 to 3,

         inclusive.  The value of profile-id MUST be in the range of 0

         to 31, inclusive.

 

         When profile-space is not present, a value of 0 MUST be

         inferred.  When profile-id is not present, a value of 1 (i.e.

         the Main profile) MUST be inferred.

 

         When used to indicate properties of a bitstream, profile-space

         and profile-id are derived from the profile, tier, and level

         syntax elements in SPS or VPS NAL units as follows, where

         general_profile_space, general_profile_idc,

         sub_layer_profile_space[j], and sub_layer_profile_idc[j] are

         specified in [HEVC]:

 

            If the RTP stream is the highest RTP stream, the following

            applies:

 

            o profile_space = general_profile_space

            o profile_id = general_profile_idc

 

            Otherwise (the RTP stream is a dependee RTP stream), the

            following applies, with j being the value of the sprop-sub-

            layer-id parameter:

 

            o profile_space = sub_layer_profile_space[j]

            o profile_id = sub_layer_profile_idc[j]

 

      tier-flag, level-id:

 

         The value of tier-flag MUST be in the range of 0 to 1,

         inclusive.  The value of level-id MUST be in the range of 0

         to 255, inclusive.

 

         If the tier-flag and level-id parameters are used to indicate

         properties of a bitstream, they indicate the tier and the

         highest level the bitstream complies with.

 

         If the tier-flag and level-id parameters are used for

         capability exchange, the following applies.  If max-recv-

         level-id is not present, the default level defined by level-id

         indicates the highest level the codec wishes to support.

         Otherwise, max-recv-level-id indicates the highest level the

         codec supports for receiving.  For either receiving or

         sending, all levels that are lower than the highest level

         supported MUST also be supported.

 

         If no tier-flag is present, a value of 0 MUST be inferred and

         if no level-id is present, a value of 93 (i.e. level 3.1) MUST

         be inferred.

 

         When used to indicate properties of a bitstream, the tier-flag

         and level-id parameters are derived from the profile, tier,

         and level syntax elements in SPS or VPS NAL units as follows,

         where general_tier_flag, general_level_idc,

         sub_layer_tier_flag[j], and sub_layer_level_idc[j] are

         specified in [HEVC]:

 

            If the RTP stream is the highest RTP stream, the following

            applies:

 

            o tier-flag = general_tier_flag

            o level-id = general_level_idc

 

            Otherwise (the RTP stream is a dependee RTP stream), the

            following applies, with j being the value of the sprop-sub-

            layer-id parameter:

 

            o tier-flag = sub_layer_tier_flag[j]

            o level-id = sub_layer_level_idc[j]

 

      interop-constraints:

 

         A base16 [RFC4648] (hexadecimal) representation of six bytes

         of data, consisting of progressive_source_flag,

         interlaced_source_flag, non_packed_constraint_flag,

         frame_only_constraint_flag, and reserved_zero_44bits.

 

         If the interop-constraints parameter is not present, the

         following MUST be inferred:

 

            o progressive_source_flag = 1

            o interlaced_source_flag = 0

            o non_packed_constraint_flag = 1

            o frame_only_constraint_flag = 1

            o reserved_zero_44bits = 0

 

         When the interop-constraints parameter is used to indicate

         properties of a bitstream, the following applies, where

         general_progressive_source_flag,

         general_interlaced_source_flag,

         general_non_packed_constraint_flag,

         general_non_packed_constraint_flag,

         general_frame_only_constraint_flag,

         general_reserved_zero_44bits,

         sub_layer_progressive_source_flag[j],

         sub_layer_interlaced_source_flag[j],

         sub_layer_non_packed_constraint_flag[j],

         sub_layer_frame_only_constraint_flag[j], and

         sub_layer_reserved_zero_44bits[j] are specified in [HEVC]:

 

            If the RTP stream is the highest RTP stream, the following

            applies:

 

            o progressive_source_flag = general_progressive_source_flag

            o interlaced_source_flag = general_interlaced_source_flag

            o non_packed_constraint_flag =

                              general_non_packed_constraint_flag

            o frame_only_constraint_flag =

                              general_frame_only_constraint_flag

            o reserved_zero_44bits = general_reserved_zero_44bits

 

            Otherwise (the RTP stream is a dependee RTP stream), the

            following applies, with j being the value of the sprop-sub-

            layer-id parameter:

 

            o progressive_source_flag =

                              sub_layer_progressive_source_flag[j]

            o interlaced_source_flag =

                              sub_layer_interlaced_source_flag[j]

            o non_packed_constraint_flag =

                              sub_layer_non_packed_constraint_flag[j]

            o frame_only_constraint_flag =

                              sub_layer_frame_only_constraint_flag[j]

            o reserved_zero_44bits = sub_layer_reserved_zero_44bits[j]

 

         Using interop-constraints for capability exchange results in a

         requirement on any bitstream to be compliant with the interop-

         constraints.

 

      profile-compatibility-indicator:

 

         A base16 [RFC4648] representation of four bytes of data.

 

         When profile-compatibility-indicator is used to indicate

         properties of a bitstream, the following applies, where

         general_profile_compatibility_flag[j] and

         sub_layer_profile_compatibility_flag[i][j] are specified in

         [HEVC]:

 

            The profile-compatibility-indicator in this case indicates

            additional profiles to the profile defined by

            profile_space, profile_id, and interop-constraints the

            bitstream conforms to.  A decoder that conforms to any of

            all the profiles the bitstream conforms to would be capable

            of decoding the bitstream.  These additional profiles are

            defined by profile-space, each set bit of profile-

            compatibility-indicator, and interop-constraints.

 

            If the RTP stream is the highest RTP stream, the following

            applies for each value of j in the range of 0 to 31,

            inclusive:

 

            o bit j of profile-compatibility-indicator =

                  general_profile_compatibility_flag[j]

 

            Otherwise (the RTP stream is a dependee RTP stream), the

            following applies for i equal to sprop-sub-layer-id and for

            each value of j in the range of 0 to 31, inclusive:

 

           o bit j of profile-compatibility-indicator =

                  sub_layer_profile_compatibility_flag[i][j]

 

         Using profile-compatibility-indicator for capability exchange

         results in a requirement on any bitstream to be compliant with

         the profile-compatibility-indicator.  This is intended to

         handle cases where any future HEVC profile is defined as an

         intersection of two or more profiles.

 

         If this parameter is not present, this parameter defaults to

         the following: bit j, with j equal to profile-id, of profile-

         compatibility-indicator is inferred to be equal to 1, and all

         other bits are inferred to be equal to 0.

 

      sprop-sub-layer-id:

 

         This parameter MAY be used to indicate the highest allowed

         value of TID in the bitstream.  When not present, the value of

         sprop-sub-layer-id is inferred to be equal to 6.

 

         The value of sprop-sub-layer-id MUST be in the range of 0

         to 6, inclusive.

 

      recv-sub-layer-id:

 

         This parameter MAY be used to signal a receiver's choice of

         the offered or declared sub-layer representations in the

         sprop-vps.  The value of recv-sub-layer-id indicates the TID

         of the highest sub-layer of the bitstream that a receiver

         supports.  When not present, the value of recv-sub-layer-id is

         inferred to be equal to the value of the sprop-sub-layer-id

         parameter in the SDP offer.

 

         The value of recv-sub-layer-id MUST be in the range of 0 to 6,

         inclusive.

 

      max-recv-level-id:

 

         This parameter MAY be used to indicate the highest level a

         receiver supports.  The highest level the receiver supports is

         equal to the value of max-recv-level-id divided by 30.

 

         The value of max-recv-level-id MUST be in the range of 0

         to 255, inclusive.

 

         When max-recv-level-id is not present, the value is inferred

         to be equal to level-id.

 

         max-recv-level-id MUST NOT be present when the highest level

         the receiver supports is not higher than the default level.

 

      tx-mode:

 

         This parameter indicates whether the transmission mode is SSM

         or MSM.

         The value of tx-mode MUST be equal to either "MSM" or "SSM".

         When not present, the value of tx-mode is inferred to be equal

         to "SSM".

 

         If the value is equal to "MSM", MSM MUST be in use.  Otherwise

         (the value is equal to "SSM"), SSM MUST be in use.

 

         The value of tx-mode MUST be equal to "MSM" for all RTP

         sessions in an MSM.

 

      sprop-vps:

 

         This parameter MAY be used to convey any video parameter set

         NAL unit of the bitstream for out-of-band transmission of

         video parameter sets.  The parameter MAY also be used for

         capability exchange and to indicate sub-stream characteristics

         (i.e. properties of sub-layer representations as defined in

         [HEVC]).  The value of the parameter is a comma-separated

         (',') list of base64 [RFC4648] representations of the video

         parameter set NAL units as specified in Section 7.3.2.1 of

         [HEVC].

 

         The sprop-vps parameter MAY contain one or more than one video

         parameter set NAL unit. However, all other video parameter

         sets contained in the sprop-vps parameter MUST be consistent

         with the first video parameter set in the sprop-vps parameter.

         A video parameter set vpsB is said to be consistent with

         another video parameter set vpsA if any decoder that conforms

         to the profile, tier, level, and constraints indicated by the

         12 bytes of data starting from the syntax element

         general_profile_space to the syntax element general_level_id,

         inclusive, in the first profile_tier_level( ) syntax structure

         in vpsA can decode any bitstream that conforms to the profile,

         tier, level, and constraints indicated by the 12 bytes of data

         starting from the syntax element general_profile_space to the

         syntax element general_level_id, inclusive, in the first

         profile_tier_level( ) syntax structure in vpsB.

      sprop-sps:

 

         This parameter MAY be used to convey sequence parameter set

         NAL units of the bitstream for out-of-band transmission of

         sequence parameter sets.  The value of the parameter is a

         comma-separated (',') list of base64 [RFC4648] representations

         of the sequence parameter set NAL units as specified in

         Section 7.3.2.2 of [HEVC].

 

      sprop-pps:

 

         This parameter MAY be used to convey picture parameter set NAL

         units of the bitstream for out-of-band transmission of picture

         parameter sets.  The value of the parameter is a comma-

         separated (',') list of base64 [RFC4648] representations of

         the picture parameter set NAL units as specified in Section

         7.3.2.3 of [HEVC].

 

      sprop-sei:

 

         This parameter MAY be used to convey one or more SEI messages

         that describe bitstream characteristics.  When present, a

         decoder can rely on the bitstream characteristics that are

         described in the SEI messages for the entire duration of the

         session, independently from the persistence scopes of the SEI

         messages as specified in [HEVC].

 

         The value of the parameter is a comma-separated (',') list of

         base64 [RFC4648] representations of SEI NAL units as specified

         in Section 7.3.2.4 of [HEVC].

 

            Informative note: Intentionally, no list of applicable or

            inapplicable SEI messages is specified here.  Conveying

            certain SEI messages in sprop-sei may be sensible in some

            application scenarios and meaningless in others.  However,

            a few examples are described below:

 

           1) In an environment where the bitstream was created from

               film-based source material, and no splicing is going to

               occur during the lifetime of the session, the film grain

               characteristics SEI message or the tone mapping

               information SEI message are likely meaningful, and

               sending them in sprop-sei rather than in the bitstream

               at each entry point may help saving bits and allows to

               configure the renderer only once, avoiding unwanted

               artifacts.

           2) The structure of pictures information SEI message in

               sprop-sei can be used to inform a decoder of information

               on the NAL unit types, picture order count values, and

               prediction dependencies of a sequence of pictures.

               Having such knowledge can be helpful for error recovery.

           3) Examples for SEI messages that would be meaningless to

               be conveyed in sprop-sei include the decoded picture

               hash SEI message (it is close to impossible that all

               decoded pictures have the same hash-tag), the display

               orientation SEI message when the device is a handheld

               device (as the display orientation may change when the

               handheld device is turned around), or the filler payload

               SEI message (as there is no point in just having more

               bits in SDP).

 

      max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, max-tc:

 

         These parameters MAY be used to signal the capabilities of a

         receiver implementation.  These parameters MUST NOT be used

         for any other purpose.  The highest level (specified by max-

         recv-level-id) MUST be such that the receiver is fully capable

        of supporting.  max-lsr, max-lps, max-cpb, max-dpb, max-br,

         max-tr, and max-tc MAY be used to indicate capabilities of the

         receiver that extend the required capabilities of the highest

         level, as specified below.

 

         When more than one parameter from the set (max-lsr, max-lps,

         max-cpb, max-dpb, max-br, max-tr, max-tc) is present, the

         receiver MUST support all signaled capabilities

         simultaneously.  For example, if both max-lsr and max-br are

         present, the highest level with the extension of both the

         picture rate and bitrate is supported.  That is, the receiver

         is able to decode bitstreams in which the luma sample rate is

         up to max-lsr (inclusive), the bitrate is up to max-br

         (inclusive), the coded picture buffer size is derived as

         specified in the semantics of the max-br parameter below, and

         the other properties comply with the highest level specified

         by max-recv-level-id.

 

            Informative note: When the OPTIONAL media type parameters

            are used to signal the properties of a bitstream, and max-

            lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and max-tc

            are not present, the values of profile-space, tier-flag,

            profile-id, profile-compatibility-indicator, interop-

            constraints, and level-id must always be such that the

            bitstream complies fully with the specified profile, tier,

            and level.

 

      max-lsr:

         The value of max-lsr is an integer indicating the maximum

         processing rate in units of luma samples per second.  The max-

         lsr parameter signals that the receiver is capable of decoding

         video at a higher rate than is required by the highest level.

 

         When max-lsr is signaled, the receiver MUST be able to decode

         bitstreams that conform to the highest level, with the

         exception that the MaxLumaSR value in Table A-2 of [HEVC] for

         the highest level is replaced with the value of max-lsr.

         Senders MAY use this knowledge to send pictures of a given

         size at a higher picture rate than is indicated in the highest

         level.

 

         When not present, the value of max-lsr is inferred to be equal

         to the value of MaxLumaSR given in Table A-2 of [HEVC] for the

         highest level.

 

         The value of max-lsr MUST be in the range of MaxLumaSR to

         16 * MaxLumaSR, inclusive, where MaxLumaSR is given in Table

         A-2 of [HEVC] for the highest level.

 

      max-lps:

         The value of max-lps is an integer indicating the maximum

         picture size in units of luma samples.  The max-lps parameter

         signals that the receiver is capable of decoding larger

         picture sizes than are required by the highest level.  When

         max-lps is signaled, the receiver MUST be able to decode

         bitstreams that conform to the highest level, with the

         exception that the MaxLumaPS value in Table A-1 of [HEVC] for

         the highest level is replaced with the value of max-lps.

         Senders MAY use this knowledge to send larger pictures at a

         proportionally lower picture rate than is indicated in the

         highest level.

 

         When not present, the value of max-lps is inferred to be equal

         to the value of MaxLumaPS given in Table A-1 of [HEVC] for the

         highest level.

 

         The value of max-lps MUST be in the range of MaxLumaPS to

         16 * MaxLumaPS, inclusive, where MaxLumaPS is given in Table

         A-1 of [HEVC] for the highest level.

 

      max-cpb:

         The value of max-cpb is an integer indicating the maximum

         coded picture buffer size in units of CpbBrVclFactor bits for

         the VCL HRD parameters and in units of CpbBrNalFactor bits for

         the NAL HRD parameters, where CpbBrVclFactor and

         CpbBrNalFactor are defined in Section A.4 of [HEVC].  The max-

         cpb parameter signals that the receiver has more memory than

         the minimum amount of coded picture buffer memory required by

         the highest level.  When max-cpb is signaled, the receiver

         MUST be able to decode bitstreams that conform to the highest

         level, with the exception that the MaxCPB value in Table A-1

         of [HEVC] for the highest level is replaced with the value of

         max-cpb.  Senders MAY use this knowledge to construct coded

         bitstreams with greater variation of bitrate than can be

         achieved with the MaxCPB value in Table A-1 of [HEVC].

 

         When not present, the value of max-cpb is inferred to be equal

         to the value of MaxCPB given in Table A-1 of [HEVC] for the

         highest level.

 

         The value of max-cpb MUST be in the range of MaxCPB to

         16 * MaxCPB, inclusive, where MaxLumaCPB is given in Table A-1

         of [HEVC] for the highest level.

 

            Informative note: The coded picture buffer is used in the

            hypothetical reference decoder (Annex C of HEVC).  The use

            of the hypothetical reference decoder is recommended in

            HEVC encoders to verify that the produced bitstream

            conforms to the standard and to control the output bitrate.

            Thus, the coded picture buffer is conceptually independent

            of any other potential buffers in the receiver, including

            de-packetization and de-jitter buffers.  The coded picture

            buffer need not be implemented in decoders as specified in

            Annex C of HEVC, but rather standard-compliant decoders can

            have any buffering arrangements provided that they can

            decode standard-compliant bitstreams.  Thus, in practice,

            the input buffer for a video decoder can be integrated with

            de-packetization and de-jitter buffers of the receiver.

 

      max-dpb:

         The value of max-dpb is an integer indicating the maximum

         decoded picture buffer size in units decoded pictures at the

         MaxLumaPS for the highest level, i.e. the number of decoded

         pictures at the maximum picture size defined by the highest

         level.  The value of max-dpb MUST be in the range of 1 to 16,

         respectively.  The max-dpb parameter signals that the receiver

         has more memory than the minimum amount of decoded picture

         buffer memory required by default, which is MaxDpbPicBuf as

         defined in [HEVC] (equal to 6).  When max-dpb is signaled, the

         receiver MUST be able to decode bitstreams that conform to the

         highest level, with the exception that the MaxDpbPicBuff value

         defined in [HEVC] as 6 is replaced with the value of max-dpb.

         Consequently, a receiver that signals max-dpb MUST be capable

         of storing the following number of decoded pictures

         (MaxDpbSize) in its decoded picture buffer:

 

                          if( PicSizeInSamplesY <= ( MaxLumaPS >> 2 ) )

              MaxDpbSize = Min( 4 * max-dpb, 16 )

           else if ( PicSizeInSamplesY <= ( MaxLumaPS >> 1 ) )

              MaxDpbSize = Min( 2 * max-dpb, 16 )

           else if ( PicSizeInSamplesY <= ( ( 3 * MaxLumaPS ) >> 2 ) )

              MaxDpbSize = Min( (4 * max-dpb) / 3, 16 )

           else

              MaxDpbSize = max-dpb

 

                        Wherein MaxLumaPS given in Table A-1 of [HEVC] for the highest

         level and PicSizeInSamplesY is the current size of each

         decoded picture in units of luma samples as defined in [HEVC].

                        The value of max-dpb MUST be greater than or equal to the

         value of MaxDpbPicBuf (i.e. 6) as defined in [HEVC].  Senders

         MAY use this knowledge to construct coded bitstreams with

         improved compression.

 

                        When not present, the value of max-dpb is inferred to be equal

         to the value of MaxDpbPicBuf (i.e. 6) as defined in [HEVC].

 

            Informative note: This parameter was added primarily to

            complement a similar codepoint in the ITU-T Recommendation

            H.245, so as to facilitate signaling gateway designs.  The

            decoded picture buffer stores reconstructed samples.  There

            is no relationship between the size of the decoded picture

            buffer and the buffers used in RTP, especially de-

            packetization and de-jitter buffers.

 

      max-br:

         The value of max-br is an integer indicating the maximum video

         bitrate in units of CpbBrVclFactor bits per second for the VCL

         HRD parameters and in units of CpbBrNalFactor bits per second

         for the NAL HRD parameters, where CpbBrVclFactor and

         CpbBrNalFactor are defined in Section A.4 of [HEVC].

 

         The max-br parameter signals that the video decoder of the

         receiver is capable of decoding video at a higher bitrate than

         is required by the highest level.

 

         When max-br is signaled, the video codec of the receiver MUST

         be able to decode bitstreams that conform to the highest

         level, with the following exceptions in the limits specified

         by the highest level:

 

          o The value of max-br replaces the MaxBR value in Table A-2

            of [HEVC] for the highest level.

          o When the max-cpb parameter is not present, the result of

            the following formula replaces the value of MaxCPB in Table

            A-1 of [HEVC]:

 

               (MaxCPB of the highest level) * max-br / (MaxBR of the

               highest level)

 

         For example, if a receiver signals capability for Main profile

         Level 2 with max-br equal to 2000, this indicates a maximum

         video bitrate of 2000 kbits/sec for VCL HRD parameters, a

         maximum video bitrate of 2200 kbits/sec for NAL HRD

         parameters, and a CPB size of 2000000 bits (2000000 / 1500000

         * 1500000).

 

         Senders MAY use this knowledge to send higher bitrate video as

         allowed in the level definition of Annex A of HEVC to achieve

         improved video quality.

 

         When not present, the value of max-br is inferred to be equal

         to the value of MaxBR given in Table A-2 of [HEVC] for the

         highest level.

 

         The value of max-br MUST be in the range of MaxBR to

         16 * MaxBR, inclusive, where MaxBR is given in Table A-2 of

         [HEVC] for the highest level.

 

            Informative note: This parameter was added primarily to

            complement a similar codepoint in the ITU-T Recommendation

            H.245, so as to facilitate signaling gateway designs.  The

            assumption that the network is capable of handling such

            bitrates at any given time cannot be made from the value of

            this parameter.  In particular, no conclusion can be drawn

            that the signaled bitrate is possible under congestion

            control constraints.

 

      max-tr:

         The value of max-tr is an integer indication the maximum

         number of tile rows.  The max-tr parameter signals that the

         receiver is capable of decoding video with a larger number of

         tile rows than the value allowed by the highest level.

 

         When max-tr is signaled, the receiver MUST be able to decode

         bitstreams that conform to the highest level, with the

         exception that the MaxTileRows value in Table A-1 of [HEVC]

         for the highest level is replaced with the value of max-tr.

         Senders MAY use this knowledge to send pictures utilizing a

         larger number of tile rows than the value allowed by the

         highest level.

 

         When not present, the value of max-tr is inferred to be equal

         to the value of MaxTileRows given in Table A-1 of [HEVC] for

         the highest level.

 

         The value of max-tr MUST be in the range of MaxTileRows to

         16 * MaxTileRows, inclusive, where MaxTileRows is given in

         Table A-1 of [HEVC] for the highest level.

 

      max-tc:

         The value of max-tc is an integer indication the maximum

         number of tile columns.  The max-tc parameter signals that the

         receiver is capable of decoding video with a larger number of

         tile columns than the value allowed by the highest level.

 

         When max-tc is signaled, the receiver MUST be able to decode

         bitstreams that conform to the highest level, with the

         exception that the MaxTileCols value in Table A-1 of [HEVC]

         for the highest level is replaced with the value of max-tc.

 

         Senders MAY use this knowledge to send pictures utilizing a

         larger number of tile columns than the value allowed by the

         highest level.

 

         When not present, the value of max-tc is inferred to be equal

         to the value of MaxTileCols given in Table A-1 of [HEVC] for

         the highest level.

 

         The value of max-tc MUST be in the range of MaxTileCols to

         16 * MaxTileCols, inclusive, where MaxTileCols is given in

         Table A-1 of [HEVC] for the highest level.

 

      max-fps:

 

         The value of max-fps is an integer indicating the maximum

         picture rate in units of pictures per 100 seconds that can be

         effectively processed by the receiver.  The max-fps parameter

         MAY be used to signal that the receiver has a constraint in

         that it is not capable of processing video effectively at the

         full picture rate that is implied by the highest level and,

         when present, one or more of the parameters max-lsr, max-lps,

         and max-br.

 

         The value of max-fps is not necessarily the picture rate at

         which the maximum picture size can be sent, it constitutes a

         constraint on maximum picture rate for all resolutions.

 

            Informative note: The max-fps parameter is semantically

            different from max-lsr, max-lps, max-cpb, max-dpb, max-br,

            max-tr, and max-tc in that max-fps is used to signal a

            constraint, lowering the maximum picture rate from what is

            implied by other parameters.

 

         The encoder MUST use a picture rate equal to or less than this

         value.  In cases where the max-fps parameter is absent the

         encoder is free to choose any picture rate according to the

         highest level and any signaled optional parameters.

 

         The value of max-fps MUST be smaller than or equal to the full

         picture rate that is implied by the highest level and, when

         present, one or more of the parameters max-lsr, max-lps, and

         max-br.

 

      sprop-max-don-diff:

 

         The value of this parameter MUST be equal to 0, if the RTP

         stream does not depend on other RTP streams and there is no

        NAL unit naluA that is followed in transmission order by any

         NAL unit preceding naluA in decoding order.  Otherwise, this

         parameter specifies the maximum absolute difference between

         the decoding order number (i.e., AbsDon) values of any two NAL

         units naluA and naluB, where naluA follows naluB in decoding

         order and precedes naluB in transmission order.

 

         The value of sprop-max-don-diff MUST be an integer in the

         range of 0 to 32767, inclusive.

 

         When not present, the value of sprop-max-don-diff is inferred

         to be equal to 0.

         When the RTP stream depends on one or more other RTP streams

         (in this case tx-mode MUST be equal to "MSM" and MSM is in

        use), this parameter MUST be present and the value MUST be

         greater than 0.

 

            Informative note: When the RTP stream does not depend on

            other RTP streams, either MSM or SSM may be in use.

 

      sprop-depack-buf-nalus:

 

         This parameter specifies the maximum number of NAL units that

         precede a NAL unit in transmission order and follow the NAL

         unit in decoding order.

 

         The value of sprop-depack-buf-nalus MUST be an integer in the

         range of 0 to 32767, inclusive.

 

         When not present, the value of sprop-depack-buf-nalus is

         inferred to be equal to 0.

 

         When the RTP stream depends on one or more other RTP streams

         (in this case tx-mode MUST be equal to "MSM" and MSM is in

         use), this parameter MUST be present and the value MUST be

         greater than 0.

 

      sprop-depack-buf-bytes:

 

         This parameter signals the required size of the de-

         packetization buffer in units of bytes.  The value of the

         parameter MUST be greater than or equal to the maximum buffer

         occupancy (in units of bytes) of the de-packetization buffer

         as specified in section 6.

 

         The value of sprop-depack-buf-bytes MUST be an integer in the

         range of 0 to 4294967295, inclusive.

 

         When the RTP stream depends on one or more other RTP streams

         (in this case tx-mode MUST be equal to "MSM" and MSM is in

         use) or sprop-max-don-diff is present and greater than 0, this

         parameter MUST be present and the value MUST be greater than

         0.

            Informative note: The value of sprop-depack-buf-bytes

            indicates the required size of the de-packetization buffer

            only.  When network jitter can occur, an appropriately

            sized jitter buffer has to be available as well.

 

      depack-buf-cap:

 

         This parameter signals the capabilities of a receiver

         implementation and indicates the amount of de-packetization

         buffer space in units of bytes that the receiver has available

         for reconstructing the NAL unit decoding order from NAL units

         carried in one or more RTP streams.  A receiver is able to

         handle any RTP stream, and all RTP streams the RTP stream

         depends on, when present, for which the value of the sprop-

         depack-buf-bytes parameter is smaller than or equal to this

         parameter.

 

         When not present, the value of depack-buf-cap is inferred to

         be equal to 4294967295.  The value of depack-buf-cap MUST be

         an integer in the range of 1 to 4294967295, inclusive.

 

            Informative note: depack-buf-cap indicates the maximum

            possible size of the de-packetization buffer of the

            receiver only.  When network jitter can occur, an

            appropriately sized jitter buffer has to be available as

            well.

 

      sprop-segmentation-id:

 

         This parameter MAY be used to signal the segmentation tools

         present in the bitstream and that can be used for

         parallelization.  The value of sprop-segmentation-id MUST be

         an integer in the range of 0 to 3, inclusive.  When not

         present, the value of sprop-segmentation-id is inferred to be

         equal to 0.

 

         When sprop-segmentation-id is equal to 0, no information about

         the segmentation tools is provided.  When sprop-segmentation-

         id is equal to 1, it indicates that slices are present in the

         bitstream.  When sprop-segmentation-id is equal to 2, it

         indicates that tiles are present in the bitstream.  When

        sprop-segmentation-id is equal to 3, it indicates that WPP is

         used in the bitstream.

 

      sprop-spatial-segmentation-idc:

 

         A base16 [RFC4648] representation of the syntax element

         min_spatial_segmentation_idc as specified in [HEVC].  This

         parameter MAY be used to describe parallelization capabilities

         of the bitstream.

 

      dec-parallel-cap:

 

         This parameter MAY be used to indicate the decoder's

         additional decoding capabilities given the presence of tools

         enabling parallel decoding, such as slices, tiles, and WPP, in

         the bitstream.  The decoding capability of the decoder may

         vary with the setting of the parallel decoding tools present

         in the bitstream, e.g. the size of the tiles that are present

         in a bitstream.  Therefore, multiple capability points may be

         provided, each indicating the minimum required decoding

         capability that is associated with a parallelism requirement,

         which is a requirement on the bitstream that enables parallel

         decoding.

 

         Each capability point is defined as a combination of 1) a

         parallelism requirement, 2) a profile (determined by profile-

         space and profile-id), 3) a highest level, and 4) a maximum

         processing rate, a maximum picture size, and a maximum video

         bitrate that may be equal to or greater than that determined

         by the highest level.  The parameter's syntax in ABNF

         [RFC5234] is as follows:

 

            dec-parallel-cap = "dec-parallel-cap={" cap-point *(","

                               cap-point) "}"

 

            cap-point = ("w" / "t") ":" spatial-seg-idc 1*(";"

                         cap-parameter)

 

            spatial-seg-idc = 1*4DIGIT ; (1-4095)

 

            cap-parameter = tier-flag / level-id / max-lsr

                           / max-lps / max-br

 

            tier-flag = "tier-flag" EQ ("0" / "1")

 

            level-id  = "level-id" EQ 1*3DIGIT ; (0-255)

 

            max-lsr   = "max-lsr" EQ  1*20DIGIT ; (0-

            18,446,744,073,709,551,615)

 

            max-lps   = "max-lps" EQ 1*10DIGIT ; (0-4,294,967,295)

 

            max-br    = "max-br"  EQ 1*20DIGIT ; (0-

            18,446,744,073,709,551,615)

 

            EQ = "="

 

         The set of capability points expressed by the dec-parallel-cap

         parameter is enclosed in a pair of curly braces ("{}").  Each

         set of two consecutive capability points is separated by a

         comma (',').  Within each capability point, each set of two

         consecutive parameters, and when present, their values, is

         separated by a semicolon (';').

 

         The profile of all capability points is determined by profile-

         space and profile-id that are outside the dec-parallel-cap

         parameter.

 

         Each capability point starts with an indication of the

         parallelism requirement, which consists of a parallel tool

         type, which may be equal to 'w' or 't', and a decimal value of

         the spatial-seg-idc parameter.  When the type is 'w', the

         capability point is valid only for H.265 bitstreams with WPP

         in use, i.e. entropy_coding_sync_enabled_flag equal to 1.

         When the type is 't', the capability point is valid only for

         H.265 bitstreams with WPP not in use (i.e.

         entropy_coding_sync_enabled_flag equal to 0).  The capability-

         point is valid only for H.265 bitstreams with

         min_spatial_segmentation_idc equal to or greater than spatial-

         seg-idc.

 

         After the parallelism requirement indication, each capability

         point continues with one or more pairs of parameter and value

         in any order for any of the following parameters:

 

            o tier-flag

            o level-id

            o max-lsr

            o max-lps

            o max-br

 

         At most one occurrence of each of the above five parameters is

         allowed within each capability point.

 

         The values of dec-parallel-cap.tier-flag and dec-parallel-

         cap.level-id for a capability point indicate the highest level

         of the capability point.  The values of dec-parallel-cap.max-

         lsr, dec-parallel-cap.max-lps, and dec-parallel-cap.max-br for

         a capability point indicate the maximum processing rate in

         units of luma samples per second, the maximum picture size in

         units of luma samples, and the maximum video bitrate (in units

         of CpbBrVclFactor bits per second for the VCL HRD parameters

         and in units of CpbBrNalFactor bits per second for the NAL HRD

         parameters where CpbBrVclFactor and CpbBrNalFactor are defined

         in Section A.4 of [HEVC]).

 

         When not present, the value of dec-parallel-cap.tier-flag is

         inferred to be equal to the value of tier-flag outside the

         dec-parallel-cap parameter.  When not present, the value of

         dec-parallel-cap.level-id is inferred to be equal to the value

         of max-recv-level-id outside the dec-parallel-cap parameter.

         When not present, the value of dec-parallel-cap.max-lsr, dec-

         parallel-cap.max-lps, or dec-parallel-cap.max-br is inferred

         to be equal to the value of max-lsr, max-lps, or max-br,

         respectively, outside the dec-parallel-cap parameter.

 

         The general decoding capability, expressed by the set of

         parameters outside of dec-parallel-cap, is defined as the

         capability point that is determined by the following

         combination of parameters: 1) the parallelism requirement

         corresponding to the value of sprop-segmentation-id equal to 0

         for a bitstream, 2) the profile determined by profile-space,

         profile-id, profile-compatibility-indicator, and interop-

         constraints, 3) the tier and the highest level determined by

         tier-flag and max-recv-level-id, and 4) the maximum processing

         rate, the maximum picture size, and the maximum video bitrate

         determined by the highest level.  The general decoding

         capability MUST NOT be included as one of the set of

         capability points in the dec-parallel-cap parameter.

 

         For example, the following parameters express the general

         decoding capability of 720p30 (Level 3.1) plus an additional

         decoding capability of 1080p30 (Level 4) given that the

         spatially largest tile or slice used in the bitstream is equal

         to or less than 1/3 of the picture size:

 

            a=fmtp:98 level-id=93;dec-parallel-cap={t:8;level-id=120}

 

         For another example, the following parameters express an

         additional decoding capability of 1080p30, using dec-parallel-

         cap.max-lsr and dec-parallel-cap.max-lps, given that WPP is

         used in the bitstream:

 

            a=fmtp:98 level-id=93;dec-parallel-cap={w:8;

                        max-lsr=62668800;max-lps=2088960}

 

            Informative note: When min_spatial_segmentation_idc is

            present in a bitstream and WPP is not used, [HEVC]

            specifies that there is no slice or no tile in the

            bitstream containing more than 4 * PicSizeInSamplesY /

            ( min_spatial_segmentation_idc + 4 ) luma samples.

 

      include-dph:

 

         This parameter is used to indicate the capability and

         preference to utilize or include decoded picture hash (DPH)

         SEI messages (See Section D.3.19 of [HEVC]) in the bitstream.

         DPH SEI messages can be used to detect picture corruption so

         the receiver can request picture repair, see Section 8.  The

         value is a comma separated list of hash types that is

         supported or requested to be used, each hash type provided as

         an unsigned integer value (0-255), with the hash types listed

         from most preferred to the least preferred.  Example:

        "include-dph=0,2", which indicates the capability for MD5

         (most preferred) and Checksum (less preferred).  If the

         parameter is not included or the value contains no hash types,

         then no capability to utilize DPH SEI messages is assumed.

         Note that DPH SEI messages MAY still be included in the

         bitstream even when there is no declaration of capability to

         use them, as in general SEI messages do not affect the

         normative decoding process and decoders are allowed to ignore

         SEI messages.

 

      Encoding considerations:

 

         This type is only defined for transfer via RTP (RFC 3550).

 

      Security considerations:

 

         See Section 9 of RFC XXXX.

 

      Public specification:

 

         Please refer to Section 13 of RFC XXXX.

 

      Additional information: None

 

      File extensions: none

 

      Macintosh file type code: none

 

      Object identifier or OID: none

 

      Person & email address to contact for further information:

 

      Intended usage: COMMON

 

      Author: See Section 14 of RFC XXXX.

 

      Change controller:

 

         IETF Audio/Video Transport Payloads working group delegated

         from the IESG.

 

 

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Fabio Vitali | 16 Aug 18:55 2014
Picon

Proposed media type registration for OASIS LegalDocML - Akoma Ntoso XML (resending)

Hello. 

I have been tasked by the OASIS LegalDocML Technical Committee to start the procedures to register a new
media type under the 'application' tree, as specified in the following.

As an explanation, Akoma Ntoso is the main expected output of the activities of the OASIS LegalDocML
Technical Committee, aimed at providing an XML vocabulary for legal and legislative documents in
national parliaments, courts and other legal institutions. Several Parliaments and legislative
bodies in the world have already decided adoption or expressed interest and support for the data format. 

Thank you.

Fabio Vitali 
(OASIS LegalDocML co-chair)

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

MIME media type name:
---------------------

   application

MIME subtype name:
------------------

   akn+xml

Required parameters:
--------------------

   None

Optional parameters:
--------------------

   charset

   with identical semantics to the charset parameter of
   the application/xml media type as specified in [RFC 3023] and 
   successors.

Encoding considerations:
------------------------

   Akoma Ntoso documents are XML, and therefore have the same
   considerations when sent as "application/akn+xml" as XML.
   See [RFC 3023] (or its successors), section 3.2.

Security considerations:
------------------------

   Since this media type uses the "+xml" convention, it shares
   the security considerations described in Section 10 of RFC 3023 
   [RFC3023], Akoma Ntoso documents may contain arbitrary URIs. 
   Hence the security issues of [RFC3986], Section 7, apply.

Interoperability considerations:
--------------------------------

   This specification describes processing semantics that dictate
   behavior that must be followed when dealing with, among other
   things, unrecognized elements. Since Akoma Ntoso is designed to 
   be extensible in specific elements, "application/akn+xml" processors 
   MAY expect that
   content received is well-formed XML, but processors SHOULD NOT
   assume that the content is valid Akoma Ntoso or expect to recognize all
   of the elements and attributes in the document.

Published specification:
------------------------

   The Akoma Ntoso specifications are an upcoming output of the LegalDocML 
   Technical Committee of OASIS. Specification of the Akoma Ntoso schema is
   available in draft form at http://www.akomantoso.org, and will be made
   available on the OASIS web site during the normal approval process. 

Applications which use this media type 
--------------------------------------

   Akoma Ntoso documents are created, accepted and managed by a number of 
   tools in use by parliaments that are active in the legal XML domain. 
   These include document management systems, legal drafting tools, URI 
   resolvers and format converters. 

   The necessity of this media types arises with those institutions that
   have another XML data format for their legal documents, and that want 
   to add support for Akoma Ntoso, since by examining the request they
   need to be able to determine the XML vocabulary to use for the response. 

Fragment identifiers
--------------------
   Documents having the media type 'application/akn+xml' use a fragment 
   identifier notation totally consistent with what is specified in [RFC3023] 
   for the media type 'application/xml'.

Restrictions on usage 
---------------------
   None. 

Provisional registration? 
-------------------------
   We kindly request provisional registration for application/akn+xml

Additional information:
-----------------------

   Magic number(s):

       There is no single initial octet sequence that is always
       present in Akoma Ntoso documents.

   File extension(s):

       Akoma Ntoso documents are most often identified with the extensions
       ".akn".

   Macintosh File Type Code(s):

       TEXT

Person and email address to contact for further information:
------------------------------------------------------------

   Fabio Vitali <fabio.vitali <at> unibo.it>
   Monica Palmirani <monica.palmirani <at> unibo.it>

Intended usage:
---------------

   COMMON

Author:
-------

The Akoma Ntoso specification is an output of the LegalDocML 
Technical Committee of the Legal XML Member Section of OASIS.

Change controller:
------------------

The OASIS Legal XML Member Section has change control over these specifications.

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

--

Fabio Vitali                            Tiger got to hunt, bird got to fly,
Dept. of Computer Science        Man got to sit and wonder "Why, why, why?'
Univ. of Bologna  ITALY               Tiger got to sleep, bird got to land,
phone:  +39 051 2094872              Man got to tell himself he understand.
e-mail: fabio <at> cs.unibo.it         Kurt Vonnegut (1922-2007), "Cat's cradle"
http://vitali.web.cs.unibo.it/
Rahman, Akbar | 21 Jul 06:38 2014

New 'coap-group+json' Internet Media Type

Hi,

 

 

 

We would like to register a new Internet Media Type for CoAP group configuration resource called 'application/coap-group+json' The proposal is described in section 6.2 of

 

http://www.ietf.org/id/draft-ietf-core-groupcomm-20.txt

 

 

Any feedback would be much appreciated.

 

 

Best Regards,

 

 

Akbar & Esko

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Chet Ensign | 17 Jun 22:45 2014

30-day Public Review for Media Type Registration Template for #XLIFF Version 2.0 - ends July 17th

OASIS members and other interested stakeholders, 

The OASIS XML Localisation Interchange File Format (XLIFF) TC [1] members have recently approved a Committee Specification Draft (CND) and submitted it for 30-day public review:

Media Type Registration Template for XLIFF Version 2.0
Committee Specification Draft 02 /Public Review Draft 01
20 May 2014

Overview:

Standalone media type registration template for XLIFF 2.0 and subsequent minor versions (2.x and 2.x.y).

TC Description:

The purpose of the OASIS XLIFF TC is to define, through extensible XML vocabularies, and promote the adoption of, a specification for the interchange of localisable software and document based objects and related metadata.

For more information, see the TC Charter and FAQ.

Public Review Period:

The public review starts 18 June 2014 at 00:00 GMT and ends 17 July 2014 at 23:59 GMT.

This is an open invitation to comment. OASIS solicits feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work.

URIs:

The prose specification document and related files are available here:

HTML (Authoritative):

PDF:

Editable source: 

ZIP distribution file (complete):

For your convenience, OASIS provides a complete package of the prose document and related files in a ZIP distribution file. You can download the ZIP file here:


Additional information about the specification and the TGF TC can be found at the TC's public home page:


Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be used by following the instructions on the TC's "Send A Comment" page, or directly at:


Comments submitted by TC non-members for this work and for other work of this TC are publicly archived and can be viewed at:


All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with this public review of "Media Type Registration Template for XLIFF Version 2.0", we call your attention to the OASIS IPR Policy [2] applicable especially [3] to the work of this technical committee. All members of the TC should be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved OASIS specification. 

OASIS invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work.

========== Additional references:

[1] OASIS XML Localisation Interchange File Format (XLIFF) TC


RF on RAND Mode 


--

/chet 
----------------
Chet Ensign
Director of Standards Development and TC Administration 
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Primary: +1 973-996-2298
Mobile: +1 201-341-1393 

Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html 

TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin

Follow OASIS on:
LinkedIn:    http://linkd.in/OASISopen
Twitter:        http://twitter.com/OASISopen
Facebook:  http://facebook.com/oasis.open
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Sujoy Gupta | 24 Mar 22:56 2014

Registering our company in the Vendor tree for use in Accepts Header

Hello,

Pursuant to http://tools.ietf.org/html/rfc4288, I am interested in registering "appdirect" in the Vendor tree. This is so that we can use headers such as Content-Type: application/vnd.appdirect.acme.v2+json without conflict with existing vendors.

Looking forward to questions or comments.

Thanks,
Sujoy Gupta
Principal Engineer, AppDirect Inc.
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
szilva | 8 Mar 16:08 2014
Picon

media type registration of the Slovak national standard for e-forms container e-form+xml, e-form+zip

Dear sirs,

I am an idependent member of working groups of the Committee for  
standardization of information systems of public administration in  
Slovak republic, which defined a national e-forms container and is  
working also on another standards. The Committee works under the  
Ministry of finance of the Slovak republic and its public website is  
here: http://informatizacia.sk/standards-for-is-pa/4632s

The e-forms container will contain all definitions, schemas and  
transformations needed for a visual and other presentations of an  
e-government e-form, for filling an e-form, validation of filled data,  
etc.

We would like to register a mimetype for this national e-forms  
container, but firstly we would like to consult the correct naming.

My questions:

1. Is there any experience with registration of media types for  
national IT or e-government standards? Are there any examples of  
national standards' subtypes?

2. I would like to ask you, what registration tree would you suggest  
for our national e-forms container. "Vendor tree" or "Personal or  
Vanity tree"?

3. What should be the "IANA-approved designation of the producer's  
name" in the case of national e-government standard? Are there any  
written rules for the names?

More explanation:

The e-forms container will be primarily used by Slovak national  
e-government portal for publication of all e-forms specifications, but  
it will be also used by vendors/software producers, who will create  
and distribute commercial or freeware software for general public and  
business customers (e.g. economical or accounting software for  
business, software for filling e-forms, software for e-signing of  
e-forms, etc). It could be possibly used by other countries or vendors.

The container has two equal forms: XML structure or ZIP container.
The technical specification of the e-forms container is published as a  
legislative document - "Edict About Standards for Information Systems  
of Public Administration" and use of this specification is imposed by  
the Slovak national legislation. (It is currently available only in  
Slovak language and the requirements for the e-forms container are  
defined in this supplement: 

https://lt.justice.gov.sk/Attachment/Priloha_3_e-formulare.pdf?instEID=-1&attEID=63268&docEID=353297&matEID=6842&langEID=1&tStamp=20140304134546663

)

The e-forms container is based on existing standards: JAR file format,  
DublinCore, Open Packaging Format, OpenDocument format, EPUB Open  
Container Format. The e-forms container also extends these standards  
for specific e-forms usage.

Currently the following nonstandard media types for e-forms containers  
are used in Slovakia:
application/e-form+zip
application/x-eform-xml

Firstly we thought, we can register something like this:
application/vnd.e-form+zip
application/vnd.e-form+xml
(maybe "e-form" will be only "eform")

But if we understand the RFC 6838 correctly, we should create an  
abbreviation for the organization which is responsible for the Slovak  
e-government IT standards and this abbreviation must be incorporated  
in the subtype name.

Maybe something like this ? :
(note, these are only examples that were not approved or consulted by  
our Committee)

application/vnd.gov.sk.e-form+zip
application/vnd.gov.sk.e-form+xml

or something like this :

application/vnd.finance.gov.sk.e-form+zip
application/vnd.finance.gov.sk.e-form+xml

Explanation for the "gov.sk": It is the second-level domain name used  
by the Slovak government organizations, such as www.government.gov.sk,  
www.finance.gov.sk, www.nases.gov.sk, etc.

As an example I filled the registration template for the XML variant  
of the container, but this is not an official registration request:

    Type name: application

    Subtype name: Vendor Tree - vnd.gov.sk.e-form+xml

    Required parameters:   None.

    Optional parameters:  "charset"

          UTF-8 is required for Slovak national e-forms containers.  
This parameter has identical semantics to the charset parameter of the  
"application/xml" media type as specified in RFC3023.

    Encoding considerations:  Identical to those of "application/xml"  
as described in RFC3023, Section 3.2.

    Security considerations:  Files may contain script and other  
active content.

    Interoperability considerations:

    Published specification:  (only in Slovak language)  
https://lt.justice.gov.sk/Attachment/Priloha_3_e-formulare.pdf?instEID=-1&attEID=63268&docEID=353297&matEID=6842&langEID=1&tStamp=20140304134546663

    Applications that use this media type:  Slovak e-government  
portals and (in the future) software from some other vendors.

    Fragment identifier considerations:

    Additional information:

      Deprecated alias names for this type:

      Magic number(s):  As specified for "application/xml" in RFC3023,  
Section 3.2.

      File extension(s):  .xml, .eform

      Macintosh file type code(s):  TEXT

    Person & email address to contact for further information:   
National agency for network and electronic services  -  or  -   
Ministry of Finance of the Slovak republic

    Intended usage: COMMON

    (One of COMMON, LIMITED USE, or OBSOLETE.)

    Restrictions on usage:

    (Any restrictions on where the media type can be used go here.)

    Author:

----

An incomplete e-forms container structure:
- mimetype - e-form mimetype
- META-INF/manifest.xml - references and paths of all of the content  
in the container
- meta.xml - e-form identification, version, name, short description  
and other metadata
- schema.xsd - XML Schema for the data.xml
- data.xml - optional - user data filled in the e-form
- Content/ - presentation schema and transformation schema of the data  
(primarily XSLT file)
- Presentation/ - optional - a presentation containing the data filled  
by an user (a result of the XSLT transformation of data.xml)
- Thumbnails/ - e-form thumbnail
- attachments.xml - optional - list of attachments
- Attachments/ - optional - attachments listed in attachments.xml
- settings.xml - optional - application settings

---

Thank you for any help

Stefan Szilva
Viglasska 7
Bratislava
Slovak republic
szilva <at> changenet.sk
Roni Even | 4 Mar 15:18 2014
Picon

registeration of G7110 media subtype for G.711.0 payload

Hi,

 

draft-ietf-payload-g7110-02 has passed Working Group Last Call in the Payload Working Group.

The document registers media subtype G7110. 

 

The new registrations are in Section 5.1 of the document and is also given bellow.

 

Comments on the registration are welcome.

 

Thanks

Roni Even

Payload WG co-chair

 

 

 

 

Media Type Registration

 

   Type name: audio

 

   Subtype name: G7110

 

   Required parameters:

 

      rate: The RTP timestamp clock rate, which is equal to the sampling

      rate.  The typical rate used with G.711 encoding is 8000, but

      other rates may be specified.  The default rate is 8000.

 

      complaw: Indicates the companding law (A-law or mu-law) employed.

      The case-insensitive values are "al" or "mu" for A-law and mu-law,

      respectively.

 

   Optional parameters:

 

      channels: See RFC 4566 [RFC4566] for definition.  Specifies how

      many audio streams are represented in the G.711.0 payload and MUST

      be present if the number of channels is greater than one.  This

      parameter defaults to 1 if not present (as per RFC 4566) and is

      typically a non-zero small-valued positive integer.  It is

      expected that implementations that specify multiple channels will

      also define a mechanism to map the channels appropriately within

      their system design, otherwise the channel order specified in RFC

      3551 [RFC3551] Section 4.1 will be assumed (e.g., left, right,

      center, ... ).

 

      maxptime: See RFC 4566 [RFC4566] for definition.

 

      ptime: See RFC 4566 [RFC4566] for definition.  The inclusion of

      "ptime" is RECOMMENDED and SHOULD be in the SDP unless there is an

      application specific reason not to include it (e.g., an

      application that has a variable ptime on a packet-by-packet

      basis).  For constant ptime applications, it is considered good

      form to include "ptime" in the SDP for session diagnostic

      purposes.  For the constant ptime multiple channel case described

      in Section 4.2.2, the inclusion of "ptime" can provide a desirable

      payload check.

 

   Encoding considerations:

 

      This media type is framed binary data (see Section 4.8 in RFC 6838

      [RFC6838]) compressed as per ITU-T Rec. G.711.0.

 

   Security considerations:

 

      See Section 10.

 

   Interoperability considerations: none

 

   Published specification:

 

      ITU-T Rec. G.711.0 and RFC XXXX.

 

      [ RFC Editor: please replace XXXXX with a reference to this RFC ]

 

   Applications that use this media type:

 

      Although initially conceived for VoIP, the use of G.711.0, like

      G.711 before it, may find use within audio and video streaming and

      /or conferencing applications for the audio portion of those

      applications.

 

   Additional information:

 

   The following applies to stored-file transfer methods:

 

         Magic numbers: #!G7110A\n or #!G7110M\n (for A-law or MU-law

         encodings respectively, see Section 6).

 

        File Extensions: None

 

         Macintosh file type code: None

 

         Object identifier or OIL: None

 

   Person & email address to contact for further information:

 

      Michael A. Ramalho <mramalho <at> cisco.com> or <mar42 <at> cornell.edu>

 

   Intended usage: COMMON

 

   Restrictions on usage:

 

      This media type depends on RTP framing, and hence is only defined

      for transfer via RTP [RFC3550].  Transport within other framing

      protocols is not defined at this time.

 

   Author: Michael A. Ramalho

 

   Change controller:

 

 

      IETF Payload working group delegated from the IESG.

 

 

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
ashimura | 27 Feb 09:01 2014
Picon

Request for review of SCXML media type: application/scxml+xml

Dear media-types list,

I am sending this request to ask you review the Media Type section of
the W3C SCXML specification.

The Media Type section of the SCXML specification is available at:

  http://www.w3.org/TR/2013/WD-scxml-20130801/#mimetype

and its plain text copy is available below.

MIME media type name:
---------------------

     application

MIME subtype name:
------------------

     scxml+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] or its
     successor.

Encoding considerations:
------------------------

     By virtue of SCXML content being XML, it has the same
     considerations when sent as "application/scxml+xml"as does
     XML. See [RFC 3023] (or its successor), section 3.2.

Security considerations:
------------------------

     SCXML elements may include arbitrary URIs. Therefore, the security
     issues of [RFC 3986] section 7 should be considered. In addition,
     because of the extensibility features for SCXML, it is possible
     that "application/scxml+xml" may describe content that has
     security implications beyond those described here. However, if the
     processor follows only the normative semantics of this
     specification, this content will be ignored. Only in the case
     where the processor recognizes and processes the additional
     content, or where further processing of that content is dispatched
     to other processors, would security issues potentially arise. And
     in that case, they would fall outside the domain of this
     registration document.

Interoperability considerations:
--------------------------------

     This specification describes processing semantics that dictate
     behavior that must be followed when dealing with, among other
     things, unrecognized elements.Because SCXML is extensible,
     conformant "application/scxml+xml" processors MAY expect that
     content received is well-formed XML, but processors SHOULD NOT
     assume that the content is valid SCXML or expect to recognize all
     of the elements and attributes in the document.

Published specification:
------------------------

     This media type registration is extracted from Appendix H of the
     State Chart XML (SCXML): State Machine Notation for Control
     Abstraction specification.

Additional information:
-----------------------

     Magic number(s):

         There is no single initial octet sequence that is always
         present in SCXML documents.

     File extension(s):

         SCXML documents are most often identified with the extensions
         ".scxml".

     Macintosh File Type Code(s):

         TEXT

Person and email address to contact for further information:
------------------------------------------------------------

     Kazuyuki Ashimura, <ashimura <at> w3.org>.

Intended usage:
---------------

     COMMON

Restrictions on usage:
----------------------

     None

Author:
-------

     The SCXML specification is a work product of the World Wide Web
     Consortium's Voice Browser Working Group.

Change controller:
------------------

     The W3C has change control over these specifications.

Sincerely,

Kazuyuki

--
Kaz Ashimura, W3C Activity Lead for Web&TV, MMI and Voice
Tel: +81 466 49 1170
Jim Schaad | 20 Feb 18:54 2014

Review for new media type registration - application/jose and application/jose+json

The document http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature is completing working group last call.  We are therefore requesting review of the registration of a new media type registration  application/jose and application/jose+json

 

The registration templates can be found in section 9.2 of the document.

 

Jim Schaad

JOSE working group co-chair

 

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types

Gmane