List of comments on “W3C mobileOK Basic Tests 1.0 (Third Last Call)” (dated 28 September 2007)

There are 20 comments (sorted by their types, and the section they are about).

typo comments

substantive comments

Comment LC-1855: Commenter: Bryan Sullivan <BS3131@att.com>; Context: 1.1.3 Out of Scope; Status:
assigned to Sean Owen; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
"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); Related issues: (space separated ids); WG Notes: Propose to resolve 'no': Maybe we just need different wording. The intent was to say "these tests only make sure you haven't done something clearly wrong" and to not say "these tests make sure you've built a nice, elegant, well-designed site." I personally feel the wording is probably as fine as anything else we could imagine. RESOLUTION: LC-1855 No We take your point but we don't think any ambiguity is introduced by this; Resolution: No We take your point but we don't think any ambiguity is introduced by this.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1859: Commenter: Laurens Holst <lholst@students.cs.uu.nl> (archived message); Context: 2.4.2 HTTP Request; Status:
assigned to Sean Owen; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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â€™.; Related issues: (space separated ids); WG Notes: Long thread on this. I (srowen) tend to agree. The change would be to specify that requests for <img src="..."/> only list image types in the accept header and so on. Propose that we rationalize this as an editorial bug fix, *or* accept this as a substantive change if there are already unavoidable other substantive changes, *or* punt if this is the only thing holding up final publication. 2007-10-31: I note that the following message from Laurens is the final exchange we had with Laurens regarding this comment, and in that message, he states, "But I still think it should be fixed." http://lists.w3.org/Archives/Public/public-bpwg-comments/2007OctDec/0001.html So we need to record this as "Commenter objected to disposition" and we need to be prepared to exmplain to the Director and others our rationale for not changing it it spite of the final objection from the commenter.; Resolution: Behavior as specified does not contravene HTTP. In practice, it is consistent with most mobile UAs behavior and is desirable on practical grounds for a tester to emulate. It should not be inferred from the way the checker behaves that real browsers either should or should not behave that way.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1857: Commenter: Bryan Sullivan <BS3131@att.com>; Context: 2.4.3 HTTP Response; Status:
assigned to Sean Owen; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
"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...).; Related issues: (space separated ids); WG Notes: Proposed to resolve 'no': We'd like to count redirects "against" the resource. Redirects are going to slow things down and if one has to go through one to get to the real resource, that should be accounted for. A 302 ought not have a body anyway; seems like wasteful overhead. RESOLUTION: LC-1857 No We are keen to minimise rounds trips and reduce the overall data transfer burden which is why it is like it is; Resolution: We are keen to minimize rounds trips and reduce the overall data transfer burden which is why it is like it is.; (Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-1854: Commenter: Bryan Sullivan <BS3131@att.com>; Context: 2.3 Testing Outcomes; Status:
assigned to Sean Owen; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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.; Related issues: (space separated ids); WG Notes: Proposed to resolve 'yes': Yeah I think a sentence of editorial clarification can't hurt. RESOLUTION: LC-1854 Yes, we think a note of clarification is warranted e.g. that it can't be determined, that it may be because it is dubious practice that in some circumstances can't be avoided; Resolution: Yes, we think a note of clarification is warranted e.g. that it can't be determined, that it may be because it is dubious practice that in some circumstances can't be avoided.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1897: Commenter: Johannes Koch <johannes.koch@fit.fraunhofer.de> (archived message); Context: 2.4.3 HTTP Response; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
* 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.; Related issues: (space separated ids); WG Notes: Resolve yes to clarify that tests should proceed on 1xx (weird as that is) or 2xx responses. The last lines of this section indicate that most 4xx and 5xx responses will FAIL. do we just need to say that one shouldn't even run tests in this case?; Resolution: Yes, we will clarify that tests should proceed on 1xx (weird as that is) or 2xx responses. The last lines of this section indicate that most 4xx and 5xx responses will FAIL.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1858: Commenter: Bryan Sullivan <BS3131@att.com>; Context: 2.4.3 HTTP Response; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
[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.; Related issues: (space separated ids); WG Notes: Proposed to resolve 'no': The reasoning here, I believe, is that one wants to allow for testing of error pages. Hence the slightly less than crystal clear text about only FAILing if the resource under test wasn't 'supposed' to return a 404/50x. I think this may need some editing but it's not bad as is. RESOLUTION: LC-1858 Yes, partial, the bevavior is deliberate in order to allow for the testing of error pages. We will add a note clarifying this.; Resolution: The behavior is deliberate in order to allow for the testing of error pages. We will add a note clarifying this.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1856: Commenter: Bryan Sullivan <BS3131@att.com>; Context: 2.4.4 Meta http-equiv Elements; Status:
assigned to Sean Owen; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
[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).; Related issues: (space separated ids); WG Notes: Proposed to resolve 'no': I think you understand it right, that it is a requirement for the *tester* client, yes. This doc is specifying what a tester has to do, and the tests are specifying what the mobileOK content / server has to do. I think a note of clarification can't hurt, since a number of people have mistaken all of this as a requirement on mobile browsers (e.g. as if they say, mobile browsers should never accept > 20K of content or something) RESOLUTION: LC-1856 Yes, we agree that it is worth clarifying that the checkers behavior should not be taken as bing indicative of how we think a client should behave in general; Resolution: I think you understand it right, that it is a requirement for the *tester* client, yes. This doc is specifying what a tester has to do, and the tests are specifying what the mobileOK content / server has to do. I think a note of clarification can't hurt, since a number of people have mistaken all of this as a requirement on mobile browsers (e.g. as if they say, mobile browsers should never accept > 20K of content or something); (Please make sure the resolution is adapted for public consumption)

Comment LC-1898: Commenter: Johannes Koch <johannes.koch@fit.fraunhofer.de> (archived message); Context: 2.4.5 CSS Style; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
* Are values "all" and "handheld" meant case-insensitively?

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

* Is "UTF-8" meant case-insensitively?; Related issues: (space separated ids); WG Notes: Case insensitive, I believe. Resolve 'yes' to clarify. (in both cases the relevant specification says case insensitive so "yes") [Jo]; Resolution: In both cases the relevant specification says case insensitive, so "yes"; (Please make sure the resolution is adapted for public consumption)

Comment LC-1899: Commenter: Johannes Koch <johannes.koch@fit.fraunhofer.de> (archived message); Context: 2.4.6 Included Resources; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
* 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?; Related issues: (space separated ids); WG Notes: Yes, src/href as appropriate. Case insensitive, I believe. Resolve 'yes' to clarify. (suggest remove href reference in 2.4.7 instead)[Jo]; Resolution: Yes, I will add the attribute names as appropriate. Case-insensitive is correct.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1900: Commenter: Johannes Koch <johannes.koch@fit.fraunhofer.de> (archived message); Context: 2.4.7 Linked Resources; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
* "GET" -> "get"
Or is it meant case-insensitively?; Related issues: (space separated ids); WG Notes: This *is* case sensitive I think? Resolve 'yes' to clarify. RFC2616 5.1.1 the method _is_ case sensitive. Suggest "no" and leave as is [Jo]; Resolution: The method is not case-sensitive, yes. I will clarify.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1901: Commenter: Johannes Koch <johannes.koch@fit.fraunhofer.de> (archived message); Context: 2.4.8 Validity; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
* " 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."; Related issues: (space separated ids); WG Notes: Resolve 'yes', I think the original wording still communicates a logical and desired behavior but the clarification here is good I think. My view is that the note makes it clear that non CSS1 properties and @ rules are not failure and that further the special case of @media etc. is actually taken into account when evaluating CSS so I think the proposal actually decreases the value of the explanation [JR] OK I would like to make some small clarification, if not the one he gave.; Resolution: Yes we will make a small clarification here.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1902: Commenter: Johannes Koch <johannes.koch@fit.fraunhofer.de> (archived message); Context: 3.2 CACHING; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
* "If the HTTP response contains neither an Expires nor Cache-Control
header"
Is "nor Pragma" missing here?; Related issues: (space separated ids); WG Notes: Resolve 'no' -- I suggest mobileOK Basic should ignore HTTP/1.0's Pragma here for the purposes of deciding whether caching info has been communicated correctly. I am not sure Pragma is sufficient. RFC2616 14.32 Pragma is an HTTP 1.0 artefact that is specified only between the client and the server, so no. [JR]; Resolution: Pragma is an HTTP 1.0 artifact, and for our purposes here we don't want to consider this alone to be a sufficient communication of cacheability, so yes we want to leave out Pragma.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1903: Commenter: Johannes Koch <johannes.koch@fit.fraunhofer.de> (archived message); Context: 3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP; Status:
assigned to Sean Owen; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
* "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)?; Related issues: (space separated ids); WG Notes: Resolve 'no' -- we're trying to encompass any namespace/DOCTYPE that is trying to be read as an HTML variant. Um, think I agree 'no' but specifically we mean "no namespace" html is also an html document. OTOH it's a fair point to say that <html xmlns="http://html.mobi/haughty/terminology/markup/language"> is not trying to be html-as-we-know-it. [JR]; Resolution: No there are no restrictions -- the test is intended to proceed to test any document that appears to be an HTML variant, and here that means any document starting with <html> regardless of namespace.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1904: Commenter: Johannes Koch <johannes.koch@fit.fraunhofer.de> (archived message); Context: 3.5 DEFAULT_INPUT_MODE; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
* "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?; Related issues: (space separated ids); WG Notes: This is probably quite a corner case but yes I'd say also include inputs with missing type attribute for this reason. Resolve 'yes'.; Resolution: Yes, probably a corner case but a good point.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1905: Commenter: Johannes Koch <johannes.koch@fit.fraunhofer.de> (archived message); Context: 3.6 EXTERNAL_RESOURCES; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
* "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)?; Related issues: (space separated ids); WG Notes: Resolve 'no' in the sense that, yes, this is correct as stated I think.; Resolution: Yes, it causes this test to fail -- this was the intent of this sentence, right.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1906: Commenter: Johannes Koch <johannes.koch@fit.fraunhofer.de> (archived message); Context: 3.10 LINK_TARGET_FORMAT; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
* "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?; Related issues: (space separated ids); WG Notes: Resolve 'yes' to clarify that this can only generate a warning when Content-Type explicitly states a charset that is inconsistent. iirc the point is to warn if the charset parameter is absent and it is inconsistent if it is absent [since we don't regard there as being a meaningful default] - so "yes" but we generate a warn especially when the charset aprameter is absent..; Resolution: Yes, a missing charset parameter would be considered inconsistent too. We will clarify.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1907: Commenter: Johannes Koch <johannes.koch@fit.fraunhofer.de> (archived message); Context: 3.15 OBJECTS_OR_SCRIPT; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
* "If the innermost nested object element content consists only of white
space (see 2.4.9 White Space), FAIL"
"consists" -> "contains"?; Related issues: (space separated ids); WG Notes: "consists only of" -> "contains only" Both seem fine but I am happy to take the change. Resolve 'yes'.; Resolution: OK.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1908: Commenter: Johannes Koch <johannes.koch@fit.fraunhofer.de> (archived message); Context: 3.21 STYLE_SHEETS_USE; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
* "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?; Related issues: (space separated ids); WG Notes: Resolve 'yes' I think to clarify that the test can only reasonably be expected to know whether a property requires a unit if the property is known to the test, and so far we have limited the test to CSS 1. [yes that was the intention, definitely JR]; Resolution: The intention was that the test can only reasonably be expected to know whether a property requires a unit if the property is known to the test, and so far we have limited the test to CSS 1.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1909: Commenter: Johannes Koch <johannes.koch@fit.fraunhofer.de> (archived message); Context: 3.22 TABLES_ALTERNATIVES; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
* "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.; Related issues: (space separated ids); WG Notes: Resolve 'yes' to change 3.23 and 3.24. 3.22 I think should stand as the test is "don't use tables" and it seems correct to fail on the first occurrence only.; Resolution: We'll change 3.23 and 3.24. I think the current wording is OK for 3.22 since that test check for existence of tables, period.; (Please make sure the resolution is adapted for public consumption)

Add a comment.