RE: [MEDIA_PIPELINE_TF] HTML media errors

 I understand that vagueness is not good but my point is to have a flexible solution. If I make a brief proposal. Here are 3 new attributes only when network error occurs with code MEDIA_ERR_NETWORK:

Protocol - indicate which protocol replied with error. This can be enumerated
        DNS - 0
        TCP - 1
        TLS - 2
        HTTP - 3
        RTSP - 4
        etc
ResponseHeader - string the is in the reply header
ResponseText - string with any details included in the body of the reply

The ResponseHeader and ResponseText I took inspiration from XHR. A problem is that some of the errors in Mark's list are not based on a reply from the server at the other end but is a local behaviour.

Regards,
JanL

-----Original Message-----
From: Giuseppe Pascale [mailto:giuseppep@opera.com]
Sent: den 14 november 2011 15:03
To: Mark Watson; Jan Lindquist
Cc: Silvia Pfeiffer; Vickers, Mark; public-web-and-tv@w3.org WG
Subject: Re: [MEDIA_PIPELINE_TF] HTML media errors

My I suggest to move quickly this discussion on a bugzilla bug? Is important to get implementers feedbacks on this.

BTW I also think (with Mark) that the HTML WG will not accept anything that is vague and is not implementable. The HTML spec must be self contained and implementable, cannot rely on undefined external specs (with few exceptions where it make sense)

Note also that too detailed error codes may be objected by the group for privacy/security concerns, especially if you are fetching a video cross-origin.

Finally, we also need to keep in mind levels of abstraction. Bringing up to the application layer errors that come from layers further down in the network stack may be not easily implementable without a significant change in the browser architecture and may be rejected by implementers in this phase (LC)


/g


On Mon, 14 Nov 2011 09:45:27 +0100, Jan Lindquist <jan.lindquist@ericsson.com> wrote:

> Hi Mark,
>
> The points I made on your proposal are as follows:
>
> 1. Numbering of the error codes. They will change over time and new
> http or tcp codes may be added. The numbering will be off in the longer term.
>
> 2. There are 2 additional levels to the error codes. It seemed overkill.
> Would suggest only one level.
>
> 3. There is no support for other protocols that you have not specified
> that control media player.
>
> I can skip writing a new proposal if you think it will be hard to
> argue for the general approach of using a string with a generic
> structure. I can agree it may be too loose. If we can address (1) and
> (3) I will be happy.
>
> Regards,
> JanL
>
> -----Original Message-----
> From: Mark Watson [mailto:watsonm@netflix.com]
> Sent: den 11 november 2011 18:59
> To: Jan Lindquist
> Cc: Silvia Pfeiffer; Vickers, Mark; public-web-and-tv@w3.org WG
> Subject: Re: [MEDIA_PIPELINE_TF] HTML media errors
>
>
> On Nov 11, 2011, at 7:02 AM, Jan Lindquist wrote:
>
>> Hello Mark,
>>
>> As you suggest I will work on a counter proposal and upload it to MPTF.
>> Hope to provide this as input before the next MPTF phone conference.
>
> Ok, but really, what is your counter-argument to the likely position
> of the HTML WG that script writers need certainty in the set of errors
> that will be reported so that they know how to handle them ? How do
> you counter that argument without the assumption that there are "parts
> of the web" (read, 'devices compliant to some additional
> specification') where the errors are specifically defined in more
> detail and other "parts of the web" where they are not ? I think there
> is a strong desire to avoid the fragmentation that "parts of the web"
> implies and I don't think we'll get away with proposals that assume
> that fragmentation. The underlying issue should be addressed directly,
> not via miscellaneous proposals on technical details.
>
> ...Mark
>
>>
>> Regards,
>> JanL
>>
>> -----Original Message-----
>> From: Mark Watson [mailto:watsonm@netflix.com]
>> Sent: den 8 november 2011 22:36
>> To: Jan Lindquist
>> Cc: Silvia Pfeiffer; Vickers, Mark; public-web-and-tv@w3.org WG
>> Subject: Re: [MEDIA_PIPELINE_TF] HTML media errors
>>
>>
>> On Nov 8, 2011, at 1:01 AM, Jan Lindquist wrote:
>>
>>> Hi Mark,
>>>
>>> I would not suggest to standardize the error details. It is too
>>> controversial to try to list "any" list, even one addition will cause
>>> a debate. This is the reason i am suggesting simply a new "result"
>>> attribute which is not mandatory (can try to make it mandatory) with
>>> the purpose of simply give more details for the reason for the error.
>>
>> Ok, but again, this is not going to fly in the HTML group. It was very
>> clear to me that they will want to see an explicit - small - list of
>> well-defined values.
>>
>> The issue is ensuring consistency in what user agents report and for
>> page authors to know what to expect. For our part at Netflix it would
>> be worth our while to track what different codes different UAs reported
>> and we have the resources to deal with that complexity. The argument is
>> that other users of the web don't have those luxuries.
>>
>>>
>>> Peronsally I would like to see that there is a protocol indication in
>>> order to differentiate the error codes from different protocols. We do
>>> not need to specify which protocols.
>>>
>>> So the explanation for the new attribute can be very short without any
>>> details except to provide examples.
>>
>> You wanna draft a counter-proposal and see what people say ?
>>
>> ...Mark
>>
>>>
>>> Regards,
>>> JanL
>>>
>>> -----Original Message-----
>>> From: Mark Watson [mailto:watsonm@netflix.com]
>>> Sent: den 8 november 2011 00:44
>>> To: Jan Lindquist
>>> Cc: Silvia Pfeiffer; Vickers, Mark; public-web-and-tv@w3.org WG
>>> Subject: 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>>
>


--
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Monday, 14 November 2011 15:06:56 UTC