Re: [MEDIA_PIPELINE_TF] HTML media errors

Jan,

Do you mean that we should have a string and should specific in HTML the exact list of possible values that the string can take ?

Or do you mean that it should be open for implementors to return error codes that are not in the explicit list in the specification ?

We discussed the latter at the Content Protection break-out on Wednesday, despite it being completely off-topic (that was my fault). Whilst I personally would be fine with such an approach, it seemed clear that this would not fly at all in the HTML working group. You also heard in the HTML group itself that even a list of 10 would be considered by some as too much to do in one step.

I think the first step has to be to get to something which could be agreed in principle in HTML. Once the principle is established, more errors can be added based on their individual merits.

If you are proposing that we specific an explicit list, I don't see much reason to have a string vs an integer. There are just as many integers as strings. We can allocate ranges to different protocol layers to keep things together if that is the concern.

Regarding other protocols, I think we need to hear from the users of those protocols that there is actually a problem. Today they have the single "network error" code and unless we hear them speak up I think we can assume that is sufficient. As a user of HTTP and HTTPS I'm speaking up to say that the single code is not sufficient for our service, so that's why my proposal only includes those layers and the ones below.

...Mark


On Nov 4, 2011, at 4:06 PM, Jan Lindquist wrote:

> Hi Mark,
> 
> Additional information is perfectly fine. My concern is trying to enumerate them and not allow it to be more flexible. You have a very basic number of HTTP error codes but there are many more. By enumerating them it will be ruff to add new ones. I hate non sequential errors for the same protocol. I agree that we cannot simply copy what is in XHR with the HTTP response header and response since the approach should be generic to TCP and other protocols behind the error. My suggestion is to "recommend" to include the protocol in question in the reason string. Again a string in order to keep flexible for any new codes introduced to the protocol. Here is a possible solution on the format:
> 
> <protocol>:<reason>
> 
> Examples
> 
> http: 302 redirect
> tcp: timeout
> 
> Another concern is that there are other protocols that you have not included (rtsp, igmp, etc) and I would be concerned to try to specify them all.
> 
> Regards,
> JanL
> 
> ________________________________________
> From: Mark Watson [watsonm@netflix.com]
> Sent: Friday, November 04, 2011 11:30 PM
> To: Silvia Pfeiffer
> Cc: Jan Lindquist; Vickers, Mark; public-web-and-tv@w3.org WG
> Subject: Re: [MEDIA_PIPELINE_TF] HTML media errors
> 
> Hi Silvia,
> 
> What is below is very specific to HTTP. The "status" field below is equal to the httpcode field I proposed for the specific case of HTTP response errors. i.e. what is below is more detail below one of the 12 or so cases I identifier.
> 
> In terms of adapting this approach to other protocols (DNS, TCP, TLS are the ones which concern me), the idea of status codes with associated status text and the response headers is again HTTP-specific.
> 
> The only thing to generalize is the idea of a status code itself (readonly attribute unsigned short status). I guess we could look in the IP, TCP and TLS specifications and directly reference the error codes which occur within them, however in practice these error codes don't appear verbatim on socket APIs. Instead you get a specific set of API-specific error codes. For example in Berkeley sockets you get ECONNREFUSED in response to the connect() call if the connection is refused by the remote host. There are also errors which are not signaled in the protocol (e.g. timeouts and possibly some TLS certificate issues).
> 
> This is why I took the approach of identifying - in an implementation-independent way - the main classes of error event that can happen. This is certainly quite high level, but would already be very valuable information for operational purposes.
> 
> ...Mark
> 
> On Nov 4, 2011, at 1:14 PM, Silvia Pfeiffer wrote:
> 
>> Hi Mark,
>> 
>> Did you look at the XMLHttpRequest  way of dealing with http
>> error/response codes?
>> http://www.w3.org/TR/XMLHttpRequest/#the-status-attribute
>> 
>> I would think that if we design in-depth error handling for media
>> elements, it should be modeled on this existing way of dealing with
>> error codes.
>> 
>> It has the following IDL:
>> // response
>> readonly attribute unsigned short status;
>> readonly attribute DOMString statusText;
>> DOMString getResponseHeader(DOMString header);
>> DOMString getAllResponseHeaders();
>> readonly attribute DOMString responseText;
>> readonly attribute Document responseXML;
>> 
>> This is of course just for HTTP, but it should be possible to adapt
>> this to any protocol and then just add an indicator for what protocol
>> had a problem and gave these results.
>> 
>> Cheers,
>> Silvia.
>> 
>> 
>> On Sat, Nov 5, 2011 at 5:50 AM, Mark Watson <watsonm@netflix.com> wrote:
>>> 
>>> On Nov 4, 2011, at 11:16 AM, Jan Lindquist wrote:
>>> 
>>>> Hi,
>>>> 
>>>> Adding the granular aspect is very useful. My suggestion is to simply add a reason attribute to give the additional details. I am concerned with possible too many layers. You have 3 levels with this proposal, general error, http error and http response code. Or maybe I misunderstood.
>>> 
>>> If you mean a free-format "reason" string field, this is very unlikely to fly in HTML - I floated it in the Content Protection breakout and got a pretty negative response from the HTML people there.
>>> 
>>> The three layers are (i) the existing error code (~3 values) (ii) more specific code for network errors (iii) http error code in the specific case of http errors.
>>> 
>>> Layers are good for errors, because scripts can choose what level of detail they are interested in.
>>> 
>>>> 
>>>> The question is what can be done with the error reason. Does it need to be formalized so the application can take different actions based on reason or is it simply to facilitate support. I believe the intention is the later, simply facilitate support. So simply a string and not necessarily code is needed.
>>> 
>>> I believe we need specific well-defined values to get it into HTML.
>>> 
>>> ...Mark
>>> 
>>> 
>>>> 
>>>> Regards,
>>>> JanL
>>>> 
>>>> ________________________________
>>>> From: Vickers, Mark [Mark_Vickers@cable.comcast.com]
>>>> Sent: Friday, November 04, 2011 6:05 PM
>>>> To: Mark Watson
>>>> Cc: public-web-and-tv@w3.org WG
>>>> Subject: Re: [MEDIA_PIPELINE_TF] HTML media errors
>>>> 
>>>> This is a great start. The backwards compatibility is good.
>>>> 
>>>> Should we reference to the IETF protocol documents which define the errors (DNS, TCP, TLS, HTTP, ...) for the error code list and meanings?
>>>> 
>>>> Also, how were these errors chosen out of all errors defined in those specs?
>>>> 
>>>> Thanks,
>>>> mav
>>>> 
>>>> On Nov 4, 2011, at 9:05 AM, Mark Watson wrote:
>>>> 
>>>> All,
>>>> 
>>>> I put up a proposal for additional network-related errors at http://www.w3.org/2011/webtv/wiki/MPTF/HTML_Error_codes
>>>> 
>>>> I would hope these would be uncontroversial and so could be added to one of the existing LC1 bugs as a concrete proposal for discussion.
>>>> 
>>>> I suggest we discuss these a little on this list and then link them from the appropriate bug.
>>>> 
>>>> ...Mark
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>

Received on Monday, 7 November 2011 23:44:22 UTC