List of comments on “W3C mobileOK Basic Tests 1.0 (Fourth Last Call)” (dated 10 June 2008)

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

editorial comments

Comment LC-2159: Commenter: Thomas Roessler <tlr@w3.org> on behalf of Web Security Context Working Group (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:
Hello,

this is a post last call comment concerning the mobile OK basic
tests 1.0, on behalf of the Web Security Context Working Group.

We notice that section 2.4.3 - HTTP Response - uses the notion of an
"HTTPS response". There is no such thing.

We also notice that the notion of an "invalid certificate" does not
match what we understand to be the Best Practice Working Group's
intention with this test.

We propose that you update this criterion, at a minimum, as follows:

If the resource is accessed through HTTPS:
If the certificate presented does not match the
resource's URI, FAIL.

If the certificate has expired or is not yet valid, warn.

If certificate validation otherwise fails, FAIL.

Checker SHOULD consider arbitrary root certificates (including
self-signed certificates) as trusted for the purposes of
mobileOK testing.

Note that there are additional error conditions that can occur
during TLS negotiation, including a mismatch on supported algorithms
and protocol versions.

Regards,; Related issues: (space separated ids); WG Notes:; Resolution: We added a section on HTTPS that refines the algorithm of determining an invalid https certificate.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1991: Commenter: Francois Daoust <fd@w3.org> (archived message); Context: 2.4.3 HTTP Response (Treatment of HTTP Status 401 responses); Status:
assigned to François Daoust; 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:
* About the treatment of HTTP Status 401:
- Why should tests be applied to the response body of such an HTTP
response? The body will never be touched by any browser during the first
pass (when authentication credentials have not already been sent)
AFAICT. Besides, it wouldn't make any sense to display the resource if
it's an included image for instance. It's perfectly normal to count the
response in EXTERNAL_RESPONSE and PAGE_SIZE_LIMIT, but I suggest
updating the "Carry out tests on the response" to "Do not carry out
tests on the response", especially given the fact that the tests FAIL
when credentials are wrong (and so there's no need to test the response
body anyway even for the second pass)
- "Re-request the resource using authentication information" could
deserve some clarification. What if the checker doesn't have any
authentication information? I would clarify this with "Re-request the
resource using authentication information if available or FAIL" (where
FAIL would be HTTP_RESPONSE-7); Related issues: (space separated ids); WG Notes: Propose to resolve as "partial". We kept the part on running the tests on the 401 response. We clarified that the test should FAIL if authentication information is not available.; Resolution: On your first point, we think that the tests should be carried on the response body because, as specified in the HTTP (RFC 2616) section 10.4.2 401 Unauthorized, the body of the HTTP Status 401 response should be presented to the user if the authentication fails: "If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information" On your second point, we think that the text deserved to be clarified and updated the relevant part to state: "If authentication information was supplied in the HTTP request (i.e. authentication failed) or if no authentication information is available, FAIL" See: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r#http_response; (Please make sure the resolution is adapted for public consumption)

Comment LC-1992: Commenter: Francois Daoust <fd@w3.org> (archived message); Context: 2.4.3 HTTP Response (On Linked Resources that may return a FAIL); Status:
assigned to François Daoust; 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:
* HTTP responses and linked resources:
I understand the LINK_TARGET_FORMAT test as willing to return WARNs to the user on linked resources, and to never return any FAIL. However, there are several cases in the tests that should be carried by the checker for HTTP responses that return a FAIL, even when the resource is a linked resource:
- "If an HTTP request does not result in a valid HTTP response [...], FAIL"
- 1 case in "If the response is an HTTPS response"
- 2 cases in "If the HTTP status indicates redirection"
- "If the HTTP status represents failure (4xx), other than 404 or a request for authentication (e.g. 401), FAIL"

I guess one may argue that LINK_TARGET_FORMAT may return a FAIL message.
The last point still stands in that case: is a linked resource that
returned a 406 Not Acceptable status supposed to trigger a FAIL? I think I should be allowed to include links to external resources that are not able to serve content to the mobileOK checker in a page without losing the possibility for the page to be mobileOK. I would relax the last check to state:
"If the HTTP status represents failure (4xx), other than 404 or a
request for authentication (e.g. 401):
If the response relates to a request for a linked resource (see 2.4.7 Linked Resources), continue with the test (see 3.10 LINK_TARGET_FORMAT ) and warn
Otherwise (i.e. for included resources), FAIL"; Related issues: (space separated ids); WG Notes: Propose to resolve "partial". LINK_TARGET_FORMAT may return a FAIL, and that is for good, even if the resource is returned with an HTTP Status 406. However, HTTP Status 406 responses should not trigger a FAIL when the resource being retrieved is an object being tasted according to the 3.5.1 Object Element Processing Rule.; Resolution: Links in a Web page intended for mobile consumption are an important constituent of the user experience. The user should be able to "trust" that clicking on a link does not yield an error message. For that reason, we think that returning FAILs in the LINK_TARGET_FORMAT is indeed needed. However, it occurred to us that HTTP Status 406 responses could well be returned for resources tasted by section 3.15.1 Object Element Processing Rule, and that this should obviously not trigger a FAIL, so we relaxed that last condition in that case as you suggested: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r#http_response; (Please make sure the resolution is adapted for public consumption)

Comment LC-1978: Commenter: Dominique Hazael-Massieux <dom@w3.org> (archived message); Context: 2.4.6 Included Resources ("Note: object elements that are accessed in order to test their Content-Type HTTP header, but do not form part of the ultimate representation of the resource under test (see 3.15 OBJECTS_OR_SCRIPT ), are not considered to be included resources."); Status:
assigned to François Daoust; 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:
* when analyzing external resources (in ContentFormatSupport,
PageSizeLimit, ExternalResources), the objects and images that are set
as fallback of an object that is in an acceptable format shouldn't be
counted. For instance,
<object data="myimage.gif"><img src="myimage.png" alt=""/></object>
shouldn't trigger an error in ContentFormatSupport, the weight of
myimage.png shouldn't be counted in PageSizeLimit and ExternalResources; Related issues: (space separated ids); WG Notes: Propose to resolve "yes".; Resolution: We agree that the "myimage.png" should not trigger a CONTENT_FORMAT_SUPPORT error, and should not be taken into account in PAGE_SIZE_LIMIT and EXTERNAL_RESOURCES. This is triggered by the note in 2.4.6 Included Resources: "object elements that are accessed in order to test their Content-Type HTTP header, but do not form part of the ultimate representation of the resource under test (see 3.15 OBJECTS_OR_SCRIPT ), are not considered to be included resources". We agree that the notion of "ultimate representation of the resource" deserves to be clarified though and the note extended to resources retrieved by section 3.15.1 Object Element Processing Rule. On the light of the discussion that followed your other comment (LC-1980) on the use of the HTTP Content-Type value to taste object element, we updated the note to specify that only resources retrieved under the 3.15.1 Object Element Processing Rule whose Content-Type is image/gif or image/jpeg are considered to be Included Resources: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r#included_resources; (Please make sure the resolution is adapted for public consumption)

Comment LC-1979: Commenter: Dominique Hazael-Massieux <dom@w3.org> (archived message); Context: 2.4.6 Included Resources ("Note: object elements that are accessed in order to test their Content-Type HTTP header, but do not form part of the ultimate representation of the resource under test (see 3.15 OBJECTS_OR_SCRIPT ), are not considered to be included resources."); Status:
assigned to François Daoust; 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:
* similarly, I don't think we want to raise a ContentFormatSupport error
on <object data="myimage.png"><img src="myimage.gif" alt="" /></object>
since this is using correctly the fallback mechanism; while this gets
accepted by ObjectsOrScript, this would currently raise an error in the
way I read ContentFormatSupport;; Related issues: (space separated ids); WG Notes: Propose to resolve "yes" to clarify the notion of "part of the ultimate representation of the resource under test". The example should not trigger any FAIL because "myimage.png" does not form part of the ultimate representation of the resource under test. This notion is unclear and undefined though, and so needs to be clarified. Based on the discussions aroung LC-1980, objects that "form part of the ultimate representation" are those retrieved under 3.15.1 Object Element Processing Rule whose Content-Type is image/gif or image/jpeg.; Resolution: We agree that the example should not raise a FAIL in CONTENT_FORMAT_SUPPORT, because "myimage.png" does not form part of the ultimate representation of the resource under test, as noted in 2.4.6 Included Resources. We clarified the note in 2.4.6 Included Resources as noted in our reply to your previous comment (LC-1978) on the need to clarify which objects and images are Included Resources, and which are not.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1980: Commenter: Dominique Hazael-Massieux <dom@w3.org> (archived message); Context: 3.16 PAGE_SIZE_LIMIT (Also concerns "3.6 External Resources"); Status:
assigned to François Daoust; 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:
* I don't think "myimage.gif" should be counted as external
resources/page size limit in the following instance:
<object data="myimage.gif" type="image/png">Hello</object> - the current
text says to "include those objects whose content type is either
"image/jpeg" or "image/gif" irrespective of whether the type attribute
is specified.", but it's not clear why.; Related issues: (space separated ids); WG Notes: Propose to resolve "partial" Since there is no consistency out there in the way such objects are handled by mobile browsers, propose to resolve as "partial": 1/ the Content-Type is still being used instead of the "type" attribute to ensure we won't return a fail in situations that work fine on actual browsers. 2/ a warning was added to warn the user when the Content-Type returned by a resource does not match the one listed in the type attribute of the underlying object element; Resolution: We understand that point, but note that there is not a real consistency in the way such objects are handled by mobile browsers in practice. Some browsers download all the objects and use the HTTP Content-Type header irrespective of the presence of the type attribute, while other browsers follow the type attribute and only download objects that match values of the HTTP Accept header. We think Content Providers should "benefit" (or rather should not be "punished") for this lack of consistency in mobile browsers, and decided, in the interest of returning fewer FAIL messages: 1/ to stick to the HTTP Content-Type header to determine whether an object is rendered or the fallback mechanism has to be used. 2/ to stick to our decision not to count objects that define a type attribute not set to image/gif or image/jpeg in PAGE_SIZE_LIMIT and EXTERNAL_RESOURCES. However, since we recognize that the corresponding behavior among mobile browsers is not consistent, that it is a bad practice to have a type attribute that does not match the Content-Type of the underlying resource and that it is a good practice to define the type attribute, we also introduced two additional warning messages: "If there is no type attribute, warn" "If the Internet media type of the retrieved resource, as indicated by its Content-Type HTTP header does not match that stated in the type attribute, warn" We note that our decision introduces a slight inconsistency in the way objects are treated by the specification: on the one hand, section 3.15.1 Object Element Processing Rule says that the Object must be retrieved so that the HTTP Content-Type header may be parsed, on the other hand, section 3.16 PAGE_SIZE_LIMIT (resp. 3.6 EXTERNAL_RESOURCES) says that an object defined with a type attribute set to image/png does not count as a retrieved resource (provided its actual Content-Type is not image/gif or image/jpeg). We think that it is needed though for the above mentioned reasons.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1981: Commenter: Dominique Hazael-Massieux <dom@w3.org> (archived message); Context: 3.16 PAGE_SIZE_LIMIT (Also concerns "2.4.3 HTTP Response"); Status:
assigned to François Daoust; 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 I hit an HTTP redirect, does the size of the page served as the
redirect page counts in PAGE_SIZE_LIMIT-1 or only
under ï»¿PAGE_SIZE_LIMIT-2? I've implemented the latter since I find it
less confusing, but the spec could be clearer about it; Related issues: (space separated ids); WG Notes: Propose to resolve 'yes'.; Resolution: Yes, we agree that the text here deserved to be clarified. We updated the text consequently: - Section 3.16 PAGE_SIZE_LIMIT was clarified with regards to the treatment of HTTP response bodies that are required to retrieve a resource: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r#PAGE_SIZE_LIMIT - Section 2.4.3 HTTP Response was also amended to have the reader refer to 3.16 PAGE_SIZE_LIMIT (resp. 3.6 EXTERNAL_RESOURCES) for details of the total size (resp. count) the HTTP redirect response body should be added to: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r#http_response; (Please make sure the resolution is adapted for public consumption)

Add a comment.