W3C

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

Quick access to

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

editorial comments

Comment LC-1991
Commenter: Francois Daoust <fd@w3.org> (archived message)
Context: 2.4.3 HTTP Response (Treatment of HTTP Status 401 responses)
assigned to François Daoust
Resolution status:

* 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)
(space separated ids)
(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)
assigned to François Daoust
Resolution status:

* 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"
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

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
Not assigned
Resolution status:

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,
(space separated ids)
(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.")
assigned to François Daoust
Resolution status:

* 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
(space separated ids)
(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.")
assigned to François Daoust
Resolution status:

* 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;
(space separated ids)
(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")
assigned to François Daoust
Resolution status:

* 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.
(space separated ids)
(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")
assigned to François Daoust
Resolution status:

* 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
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: Overview.php,v 1.46 2013-10-04 08:11:33 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org