RE: [MEDIA_PIPELINE_TF] HTML media errors

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 Saturday, 5 November 2011 00:59:14 UTC