Re: [CDNi] Triggers playlist: draft-finkelman-cdni-sva-extensions-00.txt

[Ori Finkelman <[e-mail]>]

There is the CDNI protocol registry in
https://tools.ietf.org/html/rfc8006#section-7.3 but since these are used
for a different purpose it seems to me they should have a separate registry.
I am not sure about IANA media types as these are used for that specific
purpose, to serve as media types in HTTP responses, which are not what we
need.

I am starting with a new registry within the draft, if we find something
better I will switch to it.

Thanks,
Ori



On Wed, Feb 7, 2018 at 6:38 AM, Kevin J. Ma <[e-mail]>
wrote:

> (as an individual) I think an explicit type is probably better from an
> interoperability standpoint; and if you go with one, I would make it
> mandatory.  The question I would ask is: Do we need a registry for types?
> Or are there existing type specifications that we could reference/use
> (e.g., IANA media types would be great if they existed...)?
>
> Sent from my iPhone
>
> On Feb 6, 2018, at 6:40 AM, Ori Finkelman <[e-mail]> wrote:
>
> And, if we use the explicit option, is the type mandatory, or the
> implementation may choose to omit it and rely on the dCDN to be able to
> auto-detect it by file extension or format ?
>
> On Tue, Feb 6, 2018 at 9:42 AM, Ori Finkelman <[e-mail]> wrote:
>
>> Kevin, Ben,  Colleagues,
>>
>> I am working on the playlist specifications and would like to get your
>> views on the question of playlist types.
>>
>> Should it be implicit from the playlist file extension (or even from the
>> file format) for example *.m3u8 is HLS, *.ismc is MSS, *.mpd is DASH.
>> or, the palylist object should explicitly state that type of playlist,
>> for example:
>>     {
>>        "playlist": "https://www.example.com/a/b/c/1/index.m3u8",
>>        "type": hls
>>     }
>>
>> I think that the explicit option is preferable due to the following
>> + it allows to register more types
>> + it allows for private implementations to have their own private types.
>> + it allows the dCDN to advertise which types it supports via the FCI (I
>> am working on extending it to support trigger objects).
>>
>> Thanks,
>> Ori
>>
>>
>>
>>
>> On Thu, Nov 30, 2017 at 7:35 AM, Kevin Ma <[e-mail]>
>> wrote:
>>
>>> (as an individual)
>>>
>>> > [OF] >> I think the dCDN should return an error for unsupported format
>>> and the uCDN should not delegate that service to the dCDN
>>>
>>> Ideally, the uCDN would not attempt to send a playlist URL if the dCDN
>>> has not advertised the playlist URL trigger capability.
>>>
>>> > Is the uCDN expected to fallback to producing a trigger request with
>>> the URLs from the playlist enumerated as *.urls/*.patterns?
>>>
>>> I would expect so.  I think of the playlist URL more as an optional
>>> optimization.  Without this optimization, the uCDN would be using
>>> individual urls/patterns anyway -- though for prepositioning, patterns are
>>> trickier and the playlist becomes arguably more useful.
>>>
>>>
>>> On Wed, Nov 29, 2017 at 11:57 AM, Ori Finkelman <[e-mail]> wrote:
>>>
>>>> Hi Ben,
>>>> Please see some comments and answers below
>>>>
>>>> On Tue, Nov 28, 2017 at 2:28 PM, Ben Niven-Jenkins <
>>>> [e-mail]> wrote:
>>>>
>>>>> Ori, Colleagues,
>>>>>
>>>>> I just read draft-finkelman-cdni-sva-extensions-00 and have some
>>>>> comments I will send in separate emails to keep each conversation to a
>>>>> single topic.
>>>>>
>>>>>
>>>>> > On 16 Nov 2017, at 12:27, Kevin Ma <[e-mail]>
>>>>> wrote:
>>>>> >
>>>>> >   For Triggers playlist, a long time ago we decided to not deal with
>>>>> HTTP adaptive streaming to simplify the initial scope, but I think video
>>>>> and HAS awareness is probably necessary and worthwhile for us to
>>>>> re-address.  I think I like content.playlists better than playlist.urls,
>>>>> but that's a detail.
>>>>>
>>>>> Support for multiple optional playlist formats places a burden on the
>>>>> dCDN to support the multiple playlist formats. Multiple optional playlist
>>>>> formats places a burden on the uCDN, e.g. it needs to be able to handle a
>>>>> dCDN that does not support a particular playlist e.g. by transforming the
>>>>> playlist to a dCDN supported format or by falling back to a list of URLs
>>>>> carried in the triggers request.
>>>>>
>>>> [OF] >> Another option would be for the uCDN NOT to delegate traffic of
>>>> un-supported playlist format. That would motivate the dCDN to support all
>>>> of them.
>>>>
>>>>>
>>>>> Support for multiple optional playlist formats therefore (IMO) works
>>>>> against interoperability. What is the use case for requiring multiple
>>>>> optional playlist formats?
>>>>>
>>>> [OF] >> I agree that multiple formats is not in favor of
>>>> interoperability, but this is where the video industry currently stands, so
>>>> we can decide not to standardize it but then we will need to find other
>>>> solutions for the video use cases. ABR protocol awareness is something
>>>> video CDNs have to do anyway. Features like trans-packaging at the edge are
>>>> already being discussed and developed, and for trans-packaging the dCDN
>>>> cache has to be manifest type aware.
>>>> So, basically we could treat it as just a list of files, but I am not
>>>> sure it is in favor of the whole solution.
>>>>
>>>>>
>>>>> What is the envisioned model if a dCDN does not support playlists in
>>>>> trigger requests? Is the uCDN expected to fallback to producing a trigger
>>>>> request with the URLs from the playlist enumerated as *.urls/*.patterns?
>>>>>
>>>> [OF] >> I think the dCDN should return an error for unsupported format
>>>> and the uCDN should not delegate that service to the dCDN.
>>>>
>>>>
>>>>>
>>>>> Thanks
>>>>> Ben
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Ori Finkelman*Qwilt | Work: [phone] <+972%2072-222-1647> |
>>>> Mobile: [phone] <+972%2052-383-2189> | [e-mail]
>>>>
>>>
>>>
>>
>>
>> --
>>
>> *Ori Finkelman*Qwilt | Work: [phone] <072-222-1647> | Mobile:
>> [phone] <052-383-2189> | [e-mail]
>>
>
>
>
> --
>
> *Ori Finkelman*Qwilt | Work: [phone] <072-222-1647> | Mobile:
> [phone] <052-383-2189> | [e-mail]
>
>


-- 

*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
[e-mail]