Re: please reivew mobileOK Basic Tests 1.0

Thanks Laurens, we appreciate the comments. Here are some
comments and
replies that I gathered from group discussion.

On 6/7/07, Laurens Holst <lholststudents.cs.uu.nl>
wrote:
>  First, section 2.3.2 HTTP Request states:
>
> Include an Accept header indicating that Internet media
types understood by
> the default delivery context are accepted by sending
exactly this header:
>  Accept:
>
application/xhtml+xml,text/html;q=0.1,application/vnd.wap.xh
tml+xml;q=0.1,text/css,image/jpeg,image/gif
>
>
>  I think this is incorrect, text/css should NOT be
included in the Accept
> header, and image/jpeg and image/gif ONLY if the UA is
expected to support
> showing these images independantly of a document (the
mobileOK tests should
> explicitly check whether this is supported). The client
after all does not
> know how to handle a text/css file independently of XML
markup.
>
>  Instead, it should send an "Accept:
text/css" header when the CSS files
> that are linked using <link
rel="stylesheet">, <?xml-stylesheet?> or
> include. Similarly, images referenced from
<img> should send an "Accept:
> image/jpeg,image/gif" header. Aside from checking
the Accept header for the
> main page, the mobileOK tests should also check that
Accept headers send
> these values for stylesheet and image requests.

It's an interesting point. RFC 2616 says in 14.1 that Accept
*can*
indicate desired types this way, and 10.4.7 says that
servers can even
return a type not listed in the Accept header in some cases.
I bring
it up to make the point that Accept seems to be advice, and
doesn't
have to exactly enumerate acceptable types.

It seems standard practice that user agents send a fixed
string
listing all of what they support each time.

Finally it's conceivable that one might vary a document a
little bit
based on other types in the Accept header, like linking to
JPEG versus
PNG images in an <img> tag. I don't know that this is
at all common
though.

If it's not wrong, and mimics real-world user agents a
little more,
we'd very slightly prefer to keep the fixed Accept header
as-is.


>  Second, in that same section, I think saying that UAs
must send 'exactly'
> this header is not desirable. That would prevent UAs
from handling
> additional media types, such as image/png or image/svg,
and limit
> innovation. After all, the UA would not be able to
claim a mobileOK label
> anymore. The spec should say that UAs must send exactly
this or a superset
> of this header.

mobileOK Basic tests whether a resource can be delivered in
a way that
is compatible with an abstract baseline device profile, the
"Default
Delivery Context". This profile only assumes GIF and
JPEG support, so
it would be undesirable for a mobileOK Basic tests
implementation to
send a header that says that PNG is supported. The test
demands that
you demonstrate support or GIF or JPEG, so it doesn't help
to add more
types.

But this is not to say that mobileOK resources can't return
PNG or SVG
images to other real devices! mobileOK Basic says nothing
about what
you do for more capable devices. It merely wants to see that
you can
support a certain basic device that only knows JPEG and
GIF.


>  Third, in that same section, there is a requirement
that only HTTP GET
> methods can only be used. What about form submissions
with POST? Forcing
> forms to be sent with the GET method seems undesirable
and impairs the HTTP
> functionality. It seems a silly limitation too, because
if a mobileOK Basic
> application must support HTTP and HTTPS, and Basic and
Digest HTTP
> authentication, then surely support for POST would be
trivial. The mobileOK
> tests should provide tests for checking proper cache
clearing after a POST
> request has been done on a URL.

Yes, mobileOK Basic resources are welcome to use POST and
HTTPS. The
tests only use GET, and do not test URLs that require the
POST method,
but this is not the same as saying this is prohibited.

The reasoning is that POST may have side effects and we
don't want the
tester to harm servers. We should spell out this reasoning
more
clearly, in section 2.3.2.


>  Fourth, section 2.3.4 Meta http-equiv Elements: why
are these supported at
> all, especially Content-Type and Cache-Control? In
section 3.3, a <meta>
> element is listed as an option to indicate character
encoding, given that
> there is an XML declaration and this <meta> only
complicates character set
> detection, I do not see a reason for allowing this.

Good question. This would only apply in the case where there
was no
character encoding in the HTTP headers. In this case some
user agents
will look for and use values in a <meta> tag, even
though this is not
a preferred way to specify character encoding. Getting
character
encoding right is essential, so this recommendation is there
so that
resources are better "safe than sorry", even
though it's possibly
redundant.


>  Fifth, in 3.4 CONTENT_FORMAT_SUPPORT  and VALID_MARKUP
it does not
> distinguish included resources by type, that is, if
it's a stylesheet
> include, only the text/css media type should be
accepted (otherwise FAIL),
> and if it's an image include, only image/gif or
image/jpeg is accepted and
> not text/css. If it's an object include, unless the UA
is expected to
> support CSS there by showing it somehow, text/css
should also not be
> accepted.

Yes, this seems like a reasonable tightening of the test. We
will add
something along these lines -- if the resource is expected
to be a
stylesheet, it must be text/css (and be valid CSS), and
likewise for
images.


>  Sixth, in 3.10 LINK_TARGET_FORMAT, it states:
>
>
> If the Content-Type header value of the HTTP response
is not consistent
> (determined in the same way as specified in 3.3
CHARACTER_ENCODING_SUPPORT
> and CHARACTER_ENCODING_USE) with the Accept-Charset
header in 2.3.2 HTTP
> Request, warn
>  This should be a FAIL condition. Character set
mismatches are very
> undesirable (especially from an i18n perspective) and
will create
> significant hindrances for most non-English users,
whose languages have
> accents or even do not use our alphabet at all.

>From my reading of RFC 2616, 14.2, it's allowed to send
back a
character encoding which was not listed in Accept-Charset.
It's not
desirable, and this triggers a warning.

Why not a fail? This test covers external resources, which
are
possibly outside the author's control. Some felt strongly
that one
shouldn't FAIL (maybe only temporarily) on account of an
external
resource. There are arguments both ways here, but that's why
this is
considered a warning and not a failure.


>  If you want to support ISO-8859-1 in some way to make
it easier for
> existing sites to server with the mobileOK label,
ISO-8859-1 should simply
> be processed appropriately and added to the
Accept-Charset header.

Sites are welcome to send back ISO-8859-1 whenever they
like,
according to Accept-Charset or anything else. But as far as
mobileOK
Basic Tests are concerned, we want to see the ability to
return UTF-8
and test for that. That doesn't mean you always have to
return UTF-8
to real devices.

To put it slightly differently, would you want to force
Japanese sites
to return ISO-8859-1 to pass the tests?


>  Seventh, in section 3.18 POP_UPS, target attributes on
links with values
> "_self", "_parent", or
"_top" are accepted. All of these should FAIL,
> however, since their presence does not make sense (and
is a waste of
> bandwidth) considering the requirements put forth in
3.13 NO_FRAMES.

This is a good point. They're a small waste of bandwidth. I
think
we'll have to go gather some input on this and see whether
there's any
non-trivial use case for this. I believe we'd like to
considering
issuing a warning here rather than a fail since this test
really
concerns pop-ups and not frames, but let me say this is
something I
think deserves more discussion before the final draft.

Thanks as always for this valuable input!

Sean

ON FRI, 2007-06-08 AT 06:54 +0900, LAURENS HOLST WROTE:
> HI MOBILEOK WORKING GROUP.
> 
> I€™VE LOOKED AT YOUR SPECIFICATION, AND HAVE A COUPLE
OF REMARKS.

THANKS FOR THE CAREFUL REVIEW, BUT THIS THREAD IS QUICKLY
BECOMING
HARD TO MANAGE.

FOR ANY COMMENTS WHERE THE RESPONSES SO FAR HAVEN'T
ADDRESSED
THEM TO YOUR SATISFACTION, WOULD YOU PLEASE SEND THEM
AGAIN, STARTING A NEW THREAD FOR EACH MAJOR ISSUE?


-- 
DAN CONNOLLY, W3C HTTP://WWW.W3.ORG/PEOPLE/CONNOLLY/