RE: [MEDIA_PIPELINE_TF] HTML media errors

Hi Mark,

Just to highlight my objective I was proposing a framework and not on individual error codes. I agree that response headers is probably not the right name. You allow for the additional http error codes in the httpcode attribute so that is covered.

I am concerned that if I mention other protocols like RTSP I may get objections. Note the error codes from RTSP actually use the same HTTP base.

If I am the only one concerned with keeping a flexible solution and extensible for other protocols or other decode errors I withdraw my comment.

Regards,
JanL

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

Additionally 'Response Header' is a HTTP-specific term - what does it mean for the other protocols ? There are lots of Response Headers in an HTTP response - which do you want ? The whole thing ? The response headers don't include the actual error (this is in the status line).

For the other protocols you would need to specify what you actually expect to get in these fields for the various error cases. I think it's confusing then to call these 'Response Headers'.

The bottom line is that you can't get a mapping from the hundreds of protocol-specific errors that can occur to a small, useful set that is worth standardizing 'for free'. You have to consider the actual protocols one by one and choose the errors you want to expose.

...Mark



Sent from my iPhone

On Nov 14, 2011, at 7:06 AM, "Jan Lindquist" <jan.lindquist@ericsson.com> wrote:

> 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 Tuesday, 15 November 2011 20:55:26 UTC