[media-types] Re: [IANA #1448628] expert review for dr aft-pantos-hls-rfc8216bis-21 (vendor tree, conflict review)

This looks good overall, with a couple of minor nits.  Process question
answered inline.

On Thu, Apr 9, 2026 at 11:32 PM David Dong via RT <
[email protected]> wrote:

> Hi Murray,
>
> Following up on this vendor-tree conflict review request as well (#2 of 2).
>
> This is now on the 4/16 telechat.
>
> Thank you.
>
> Best regards,
>
> David Dong
> IANA Services Sr. Specialist
>
> On Wed Apr 01 23:12:11 2026, amanda.baber wrote:
> > Hi Murray,
> >
> > Sending a reminder for this vendor-tree conflict review request. #2 of 2.
> >
> > thanks,
> > Amanda
> >
> > On Thu Mar 26 21:45:55 2026, amanda.baber wrote:
> > > Hi Murray,
> > >
> > > This is the second conflict review request I have for you. This one is
> > > modifying application/vnd.apple.mpegurl:
> > >
> > > https://www.iana.org/assignments/media-
> > > types/application/vnd.apple.mpegurl
> > >
> > > The only changes I see, apart from any changes to referenced sections
> > > of the document, are the addition of a "Query parameter
> > > considerations" field and the replacement of David Singer, who I
> > > understand has retired from Apple, as change controller. Do we need to
> > > reach out to David (via a different address) to ask him to approve his
> > > replacement? Would that be necessary if Apple were to be listed as
> > > change controller rather than another Apple employee, if the existing
> > > registration should be considered a "third-party registration," as
> > > described in RFC 6838?
>

What precedent do we have for handling cases like this?

The existing registration was from someone at Apple, so I don't think it's
"third-party" any more than this one is.

I think it would be prudent to try to contact David Singer at the address
we have.  If that bounces or there's no answer, we might need to ask the
IESG for guidance.  Maybe for corporations, we should encourage these to be
roles rather than specific people to avoid this problem.


> > > See below for the template. As with the other request, this conflict
> > > review is listed as "for action" on next week's telechat agenda.
> > >
> > > thanks,
> > >  Amanda
> > >
> > > =====
> > >
> > > Type name: application
> > >
> > > Subtype name: vnd.apple.mpegurl
> > >
> > > Required parameters: none
> > >
> > > Optional parameters: none
>

These should be "N/A"; see RFC 6838 Section 5.6.


> > > Encoding considerations: encoded as UTF-8, which is 8-bit text.  This
> > > media type may require encoding on transports not capable of handling
> > > 8-bit text.  See Section 4 for more information.
>

This should just be "binary"; see RFC 6838 Section 4.8.


> > > Security considerations: See Section 12.
> > >
> > > Compression: this media type does not employ compression.
>

That field isn't in the template.


> > > Interoperability considerations: There are no byte-ordering issues
> > > since files are 8-bit text.  Applications could encounter
> > > unrecognized tags, which SHOULD be ignored.
> > >
> > > Published specification: see Section 4.
> > >
> > > Applications that use this media type: Multimedia applications such
> > > as the iPhone media player in iOS 3.0 and later and QuickTime Player
> > > in Mac OS X version 10.6 and later.
> > >
> > > Fragment identifier considerations: no Fragment Identifiers are
> > > defined for this media type.
> > >
> > > Query parameter considerations: the definition of all query
> > > parameters for resources of this media type which begin with the
> > > string "_HLS_" are reserved by this specification.  Currently-defined
> > > query parameters are specified in Section 6.2.5, Section 7.4, and
> > > Appendix D.4.
>

There's no such field in the template.  I think these details belong in the
specification document and don't need to be added here.


> > >
> > > Additional information:
> > >
> > > Deprecated alias names for this type: none
> > > Magic number(s): #EXTM3U
> > > File extension(s): .m3u8, .m3u (see Section 4)
> > > Macintosh file type code(s): none
> > >
> > > Person & email address to contact for further information: Dimitri
> > > Podborski, dpodborski AT apple.com.
> > >
> > > Intended usage: LIMITED USE
> > >
> > > Restrictions on usage: none
> > >
> > > Author: Roger Pantos
> > >
> > > Change Controller: Dimitri Podborski
>

 -MSK

_______________________________________________
media-types mailing list -- [email protected]
To unsubscribe send an email to [email protected]