Disposition of comments for the Mobile Web Best Practices Working Group

Jo Rabin schreef:
>
> Laurens
>
>
>
> Thanks for your further reply on this. Ref RFC2616
>
>
>
> Accept headers *can* be used to specify certain media
>
> types which are acceptable for the response. …
>
>
>
> Not “should” or “must”.
>

I think you’re misinterpreting that sentence, it “can” be used because
the Accept header is optional. It does not imply the Accept header can
be used differently than described, and that you can just put any kind
of nonsense in there and still expect it to work.

> And if the server needs to respond with a 3xx, 4xx or 5xx response
> code, in principle it would not know how to do that if the request did
> not contain a range of content types.
>

I don’t understand how that would be. Different content types are just
different representations of data. A single resource can be represented
by several content types. If you’re going to indicate to the server that
you accept certain representations, then the server can send any of
them. However regardless of the content type, the server knows perfectly
well when a response of 3xx, 4xx or 5xx is needed for that resource
(e.g. when it has moved or is unavailable). They’re two separate things,
and unrelated.

I do not understand the resistance against just sending the correct
Accept headers. That is how the protocol is designed, and it’s also how
browsers implement it.

Also, you’re completely glossing over my statement that sending
incorrect Accept headers *breaks* servers which correctly handle content
negotiation, because the accepted content types are not correctly
indicated by the test. Thus, with this test the W3C would force web
sites to not use content negotiation if they want to get your label for
‘correctness’.

"The tests do not assess usability, rather, they assess whether the content can be provided in a way that is likely to achieve a basic level of interoperability with mobile devices":
[bryan] The tests seem to contradict this statement. There are aspects of usability and efficiency as well as interoperability that seem to be the focus of some of the MWBP recommendations, and in the MOT, the tests. For example:
3.1 AUTO_REFRESH and REDIRECTION (efficiency)
3.2 CACHING (efficiency)
3.5 DEFAULT_INPUT_MODE (usability)
3.6 EXTERNAL_RESOURCES (efficiency)
3.7 GRAPHICS_FOR_SPACING (efficiency, unless variations in spacing as rendered are meant as an interoperability problem)
3.12 MINIMIZE (efficiency)
3.14 NON-TEXT_ALTERNATIVES (usability)
3.16 PAGE_SIZE_LIMIT (efficiency, related to to the sum of all responses from an initial request)
3.17 PAGE_TITLE (usability)
3.19 PROVIDE_DEFAULTS (usability)

"If the HTTP status indicates redirection... If the response relates to a request for the resource under test... Include the size of the response in the total described under 3.16 PAGE_SIZE_LIMIT":
[bryan] The size of response headers and content in 3xx responses should not count toward the page size total. Page size limitations in the DDC should relate to only the ultimate page returned in response to the original request (e.g. 2xx response page) and all its embedded or referenced objects that have to be retrieved (e.g. style sheets). The size of content or headers in 3xx responses is irrelevant, unless there is some transient response handling limitation (these are most commonly related to the size of the Location header URI, or excessive cookies set in the 3xx response). This comment also applies to the section for status code 401 ("Include the size of the response in the total...") and ("Include this response under the count...).

* "If the HTTP response contains neither an Expires nor Cache-Control
header"
Is "nor Pragma" missing here?

* "In the following, an "html document" is a document that has "html" as
its root element."
Are there any restrictions on the html element's namespace URI
(http://www.w3.org/1999/xhtml)?

* "FAILures that occur in the course of making this assessment
contribute to the result of this test."
Does this mean that a failure from the algorithm specified in 2.4.3
(http_response-x) creates another failure for 3.6 (EXTERNAL_RESOURCES-1)?

This should explain what "PASS" "WARN" "FAIL" imply and how these relate to the MWBP, e.g. (a) "PASS" means the content is fully compatible with the MWBP for the DDC; (b) "WARN" means the content MAY result in problems in the DDC; (c) "FAIL" means the content does not comply with the MWBP for the DDC.

[bryan] This seems to be a client behavior criteria. Since the focus of the tests is whether the *content* is interoperable, this client behavior seems to be out of scope. If this is meant as design criteria for a test client only (a client specifically designed to support this testing), then this should be clarified in "2.4 Conduct of Tests" (e.g. some description of the following "test conduct" statements as relating to the client/server test environment, and that HTTP-related aspects of the statements are not meant as criteria for DDC-compliant clients generally).

[bryan] To be consistent with the other "test environment failure" (e.g. "certificate is invalid") cases, this should result in a FAIL. For example, in this case, one would not expect a valid URI request to result in 4xx/5xx in a working test environment.

in Note: "have the have either the" -> "have either the"

* The algorithm does specify whether tests have to be carried out on
responses with 3xx, 401, 404, 407 and 5xx status codes. Is does _not_
specify whether tests have to be carried out on responses with 1xx, 2xx
and 4xx (other than 401, 404 and 407).

It does specifiy whether the resource size/count totals have to be
updated for 3xx, 401, 407 status codes. Is does _not_ specify whether
the resource size/count totals have to be updated for 1xx, 2xx, 4xx
(other than 401 and 407) and 5xx status codes.

* Are values "all" and "handheld" meant case-insensitively?

* Are "stylesheet" and "alternate" meant case-insensitively?

* Is "UTF-8" meant case-insensitively?

* While section 2.4.7 lists element/attribute combinations (e.g. href
attribute of a element), section 2.4.6 does not provide attributes for
the elements:
* img elements (src attribute?)
* object elements (data attribute? some special param, e.g. value
attribute of param element with name="src"?
* link elements and xml-stylesheet processing instructions (href
(pseudo-) attribute?)

* Are values "all" and "handheld" meant case-insensitively?

* "GET" -> "get"
Or is it meant case-insensitively?

* " CSS

A resource is considered a valid CSS resource if it conforms to the
grammar defined in [CSS], Appendix B (see note below).

Note:

The presence of at-rules, properties or values or combinations of
properties and values that are not specified in [CSS] does not
constitute a validity failure for CSS. See 3.21 STYLE_SHEETS_USE for
treatment of such values. In addition, the @media at-rule and the
presentation media qualifiers for the @import at-rule are taken into
account when evaluating CSS."

This is a contradiction: The CSS1 grammar does not allow at-rules other
than @import. How about the following wording (if that's what you mean)?

"A resource is considered a valid CSS resource if it conforms to the
grammar defined in [CSS], Appendix B, apart from possible uses of @media
at-rules with optional presentation media qualifiers."

* "For each input element with attribute type whose value is "text" or
"password""
Does a missing type attribute in the markup assume the default value
"text" as per the document type definition?

* "If the Content-Type header value of the HTTP response is not
consistent with the Accept-Charset header in 2.4.2 HTTP Request, warn"
What to do here if there is no charset parameter in the Content-Type header?

* "If the innermost nested object element content consists only of white
space (see 2.4.9 White Space), FAIL"
"consists" -> "contains"?

* "If the CSS Style contains a property with a value that is
inappropriate to it, warn

If the CSS Style contains a property with a value that requires a unit
or a percentage:

If the unit (or percentage) is not present, warn

If the unit (or percentage) is inappropriate to the value, warn"

Does this only apply to properties specified in CSS1? Do newer
properties have to be ignored here?

* "If a table element exists," -> "For each table element"?
Otherwise there would be at most one message for
"TABLES_ALTERNATIVES-1", "TABLES_LAYOUT-1", "TABLES_LAYOUT-2",
"TABLES_LAYOUT-3" and "TABLES_NESTED-1" per checked URI.