[5th Ed] @containerProfiles issues

[mikedo]

5th Ed defines it as:

specifies the container profiles of Representations that are essential to process it. The detailed semantics depend on the value of the @MimeType attribute.
The contents of this attribute shall conform to either the pro-simple or pro-fancy productions of IETF RFC 6381:2011, subclause 4.5, without the enclosing DQUOTE characters, i.e. including only the unencodedv or encodedv elements respectively.
4CC may contain characters that must be escaped in XML. 4CC strings shall be escaped according to W3C XML:2008, Section 2.4.

There are no examples.

The DASH schema types it broadly as xs:string, but has documentation that says “Whitespace separated list of 4CC“.

RFC 6381 says:

  pro-simple  := "profiles" "=" unencodedv
  pro-fancy   := "profiles*" "=" encodedv

  unencodedv  := id-simple / simp-list
  simp-list   := DQUOTE id-simple *( "," id-simple ) DQUOTE
  id-simple   := element
              ; "." reserved as hierarchy delimiter
  element     := 1*octet-sim
  octet-sim   := <any TOKEN character>

  encodedv    := fancy-sing / fancy-list
  fancy-sing  := [charset] "'" [language] "'" id-encoded
              ; Parsers MAY ignore <language>
              ; Parsers MAY support only US-ASCII and UTF-8
  fancy-list  := DQUOTE [charset] "'" [language] "'" id-list DQUOTE
              ; Parsers MAY ignore <language>
              ; Parsers MAY support only US-ASCII and UTF-8
  id-list     := id-encoded *( "," id-encoded )
  id-encoded  := encoded-elm *( "." encoded-elm )
              ; "." reserved as hierarchy delimiter
  encoded-elm := 1*octet-fancy
  octet-fancy := ext-octet / attribute-char

  DQUOTE      := %x22 ; " (double quote)

Some issues:

1. “Whitespace separated list of 4CC” does not conform to either permitted syntax above. So we need to remove that comment, I think.
2. The pro-simple syntax, unencodedv, would look like, e.g.: “iso9,cmfc”. OK, good. What is the value in using the more complex pro-fancy form, encodedv? Should we remove that form?
3. Per the RFC “.”must be escaped, but also XML forbids & and <. Other symbols have to be escaped as well, such as comma, space, double quote, unprintable, etc. So far, MP4RA Brands only have the space character in use other than alphanumeric. But a DASH client would need to expect and parse for all forms of escaped syntax to work in the future.
4. How should a DASH packager populate @containerProfiles from ftyp.major_brand and ftyp.compatible_brands[]? The most obvious - major_brand first, then all compatible_brands? Or is it application-defined?

[paulhiggs]

1. “Whitespace separated list of 4CC” does not conform to either permitted syntax above. So we need to remove that comment, I think.

Its likely that the definition was copied from @segmentProfiles and not given full consideration.
The definition as <xs:attribute name="containerProfiles" type="ListOf4CCType"/> may have similar history.

2. The pro-simple syntax, unencodedv, would look like, e.g.: “iso9,cmfc”. OK, good.

We have a definition of simp-list which could be applied to @containerProfiles

What is the value in using the more complex pro-fancy form, encodedv? Should we remove that form?

Not sure - need input from the proposer

3. Per the RFC “.”must be escaped, but also XML forbids & and <. Other symbols have to be escaped as well, such as comma, space, double quote, unprintable, etc. So far, MP4RA Brands only have the space character in use other than alphanumeric. But a DASH client would need to expect and parse for all forms of escaped syntax to work in the future.

Should @containerProfiles only support MP4RA brands, or allow any values

4. How should a DASH packager populate @containerProfiles from ftyp.major_brand and ftyp.compatible_brands[]? The most obvious - major_brand first, then all compatible_brands? Or is it application-defined?

This is probably something for be resolved through a specification issue and not just in the schema repository...

[mikedo]

Should @containerProfiles only support MP4RA brands, or allow any values

This was added with CMAF to convey the profiles parameter defined in RFC 6381. In the context of CMAF, @segmentProfiles carries one or more CMAF brands, as described in DASH 8.12.4.3. But the core definition of the syntax not so specific.

[paulhiggs]

This is probably more of a DASH DUI topic than something only for the resultant schema in this repo