search

SMPTE / ST377-1-full-revision

2 stars 0 forks source link

Leaves with OID encoding that rolls over the 0x7f max byte value #3

Open SMPTE-standards opened 7 years ago

SMPTE-standards commented 7 years ago

From email 6 Feb 2017 Does 377-1 have to deal with the following: Upcoming MXF Group UL assignments DRAFT 30mr10 has now assigned 123 leaves under node urn:smpte:ul:060e2b34.027f0101.0d010101.01010000 It is very liklely that more than 4 additional leaves will be assigned during the next few years. Leaves 0x79, 0x7a, 0x7b and 0x7c are the next to be assigned (and 0x7d, 0x7e and 0x7f are already assigned). After that, the next leaf compliant with ST298 and ST336 OID encoding will be urn:smpte:ul:060e2b34.027f0101.0d010101.01018100 then urn:smpte:ul:060e2b34.027f0101.0d010101.01018101 and so on. The upcoming 31fs revision of ST 377-1:2011 will need to address this topic in at least Table 17 Please review with your MXF-related project groups

ST 336 normatively allows bytes 9-16 > 0x7f in conformance with ST 298. ST 298 defines ULs as an ISO 8824 OID encoded per ISO 8825 BER. ST 434 allows urn:oid: representation per RFC 3061. I know of registrants that employ these provisions. I think your UL implementation needs to be enhanced to comply. ST 377-1 tables (or equivalents in other documents) will be revised to document what is assigned, not vice versa. best regards Oliver

thomasheritage commented 3 years ago

Note that such ULs have now been assigned. For further background and guidance see: https://registry.smpte-ra.org/view/draft/docs/General%20Notes/Choosing%20ULs%20for%20new%20entries/

mrmxf commented 2 years ago

We have a working practise. I propose that we document this in the revision.