On item_name being a relative URL

[podborski]

I see this text in the ISOBMFF spec in the definition of the Item Information box iinf.

The item_name shall be a valid URL (e.g. a simple name, or path name) and shall not be an absolute URL.

semantics say:

item_name is the symbolic name of the item (source file for file delivery transmissions).

To me it feels a bit confusing as the syntax element refers to a name and not a relative URL. Do implementations out there follow the shall in the definition? Is for example HEVC Image or an empty string considered a valid URL?

[bradh]

I just grep'd (ack'd) the file format conformance samples for HEIF - none of those look like URLs. A quick check of libheif and libavif-container suggests that both of those are just treating it as a string. So, it feels like the item_name should just be a descriptive string.

However comparing this to the 2015 version of 14496-12 (5th ed.), it has been added to the 2022 version (7th Ed). I don't have the 6th edition to check where. That looks like it is to support the special-case interpretation added to 8.11.9 where the item_name gets used as a relative URL ("if not empty"). So I assume someone wanted it to be a URL (or empty), and that MPEG agreed to the breaking change between Ed 5 and Ed 7 somewhere.

[leo-barnes]

I don't think I've seen any HEIF file where the item name is a URL. It's either the empty string or some kind of descriptive string of what the image is or who created it.

If this is a recent change, we should really have it reverted since it doesn't conform to reality.

[leo-barnes]

Hmmm... It's really weird to require writers to put the name/path name in the infe. What are you supposed to do if the file is renamed?