Support "individualization-request" message type

[rkuroiwa]

Encrypted Media Extensions defines "individualization-request" message type
https://www.w3.org/TR/encrypted-media/#idl-def-MediaKeyMessageType.individualization-request

For my use case, I would like to specify a URL to send the messages to, just like specifying a license server URL.

[joeyparrish]

Since it seems easy, we will try to fit it into v2.5. We just need to decide how the configuration will work.

We could create an additional URL field (per key-system) for this type of message. Or we could create a map of message type to URL (per key-system).

Or, we could add message type to the Request object, and let advanced routing based on message type be handled by request filters.

[joeyparrish]

The advantage of the request approach is that apps could handle all message types if they wish, and it wouldn't make our configuration any more complicated.

The down side is that (if I understand correctly), individualization messages won't ever be destined for the same server as licenses, so not configuring this would almost certainly lead to failures.

@rkuroiwa, is that accurate?

If individualization messages are special (must always go somewhere special), then a separate field might be a better reflection of this status, and make it easier to discover the solution to any problems encountered.

[rkuroiwa]

I don't think it is the case that "individualization messages won't ever be destined for the same server as licenses". It just happens to be that my use case needs a separate URL. It feels more like an implementation detail or business logic.
What is going to be the default behavior if the user doesn't want to special case individualization-request messages, and just want to use the same URL?

I'm ok with shaka player propagating up the message type along with a Request object but I'm guessing that most use cases is simply sending the message somewhere else, rather than changing the content of the requests. Plus it requires extra network handling in the app.

[joeyparrish]

I don't think it is the case that "individualization messages won't ever be destined for the same server as licenses". It just happens to be that my use case needs a separate URL. It feels more like an implementation detail or business logic.

I was thinking that most individualization requests would be going to some central location run by the DRM provider, and that licenses might be served by something specific to the application. If everything can be handled by the app's servers, why do we need this feature?

What is going to be the default behavior if the user doesn't want to special case individualization-request messages, and just want to use the same URL?

If a separate URL is not provided, it would default to the one provided for licenses.

I'm ok with shaka player propagating up the message type along with a Request object but I'm guessing that most use cases is simply sending the message somewhere else, rather than changing the content of the requests. Plus it requires extra network handling in the app.

A URL string config is definitely easier for an app developer than writing a filter callback. So there's that to consider.

[rkuroiwa]

I was thinking that most individualization requests would be going to some central location run by the DRM provider, and that licenses might be served by something specific to the application. If everything can be handled by the app's servers, why do we need this feature?

I think this will be the majority of the use cases. I was just replying to the "won't ever be" part.
If the default behavior uses the URL for licenses I'm not too worried about cases where they happen to be the same endpoint.

I think it's easiest for the app devs to be able to specify a separate URL for individualization requests, but I'll leave it up to you folks to design the API :)

[joeyparrish]

Okay. Then I think my gut says to offer a configurable URL string for the individualization requests, for simplicity, and to add the message type to DRM-related requests for generality. Anybody who wants the common thing can do it easily, and anybody who wants more detailed routing can still get the info they need to do that.

Thanks for talking this out!

[joeyparrish]

This feature was released in v2.5.0-beta2.