There are 5 comments (sorted by their types, and the section they are about).
general comment comments
Comment LC-1466
Commenter: Dan Connolly <connolly@w3.org> (archived message ) Context: 2.2.2 CHARACTER_ENCODING_SUPPORT
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Sean Owen
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :I see:
"If the request response does specify a character encoding but it is not
"UTF-8", FAIL"
-- http://www.w3.org/TR/mobileOK/#id4485785
How about US-ASCII? especially since you can treat US-ASCII
as UTF-8 and preserve the meaning of the bytes.
It's perhaps not worthwhile to complicate things, if very
few documents are labelled US-ASCII.
p.s. I wonder if it's acceptable to limit encodings to UTF-8
and exclude UTF-16; it wasn't when XML was ratified.
But I'll leave it to those who have 1st-hand experience
with the need for UTF-16 to comment on that.
p.p.s. The fragid #id4485785 seems fragile. If you're
going to break it, break it only once, for the next draft.
At that point, change it to something like #char-encoding-support
and keep it that way for future revisions.
Related issues: (space separated ids)
WG Notes: I responded as shown below. I believe the implicit resolution was to not require explicit US-ASCII support. Dan was OK with that. Also, I fixed the document's anchors to be more meaningful in the next draft.
"Fair point, I'll bring it up to the group. I personally am not sure
how common US-ASCII-encoded pages are, and haven't seen one in recent
memory. We assume a capability profile that includes UTF-8 support,
and as you say a valid US-ASCII-encoding of text is also a valid UTF-8
encoding of the same text, so one could label US-ASCII documents as
UTF-8.
We haven't assumed UTF-16 support in the Default Device Context, and
the tests generally assume that capability profile, so the test does
intend to verify that content can be received in UTF-8 encoding.
Agreed about the fragment IDs. This is an artifact of how the document
is generated, but, can probably be fixed in an upcoming draft.
Thanks for this valuable input,
Sean"
Resolution: Dan we discussed character encoding and US-ASCII at our weekly call.
One concern was that several Japanese phones would not recognize the
US-ASCII encoding when called "US-ASCII" and would default to
Shift_JIS instead of UTF-8. The same may be true of other handsets.
I think the position of the group would be that a document encoded as
US-ASCII is also encoded as UTF-8 and so should be declared as "UTF-8"
instead. We'd not want to tell people to assume that phones know what
US-ASCII is, as it seems there is enough lack of support to puncture
that assumption. (Please make sure the resolution is adapted for public consumption)
editorial comments
Comment LC-1465
Commenter: Susan Lesch <lesch@w3.org> (archived message ) Context: 2 mobileOK Label Test Suites (comments on CSS usage)
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Sean Owen
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :
Related issues: (space separated ids)
WG Notes: The doc was updated to reflect the spirit of all Susan's changes -- I changed her suggested wording.
Resolution: Fixed per Susan's suggestions, with different wording, in the next draft. (Please make sure the resolution is adapted for public consumption)
Comment LC-1467
Commenter: Context: 2.2.4 CONTENT_FORMAT_SUPPORT
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Sean Owen
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :
Related issues: (space separated ids)
WG Notes: I believe this was Andrea's comment titled "MOK, 2.2.4 CONTENT_FORMAT_SUPPORT" from 7/26? I replied and changed the doc according to my message, which seems to have implicitly resolved this as there were no further comments.
"The MIME types I wrote down were supposed to reflect the default
delivery context, but I neglected to include image/jpeg, yes. That's
an oversight and should be fixed. I think text/css should be included
too for completeness, yes.
An audio file is not mobileOK because it's out of the scope of
documents we're considering. I don't think we want to allow plugins as
mobileOK, no. I'm thinking of Java applets and Flash.
Otherwise I favor sticking to the current test, with the fixes above."
Resolution: Resolved per Sean's reply in the next draft (Please make sure the resolution is adapted for public consumption)
Comment LC-1468
Commenter: Susan Lesch <lesch@w3.org> (archived message ) Context: 2.2.4 CONTENT_FORMAT_SUPPORT
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Sean Owen
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Hello,
Congratulations on your First Public Working Draft [1] for mobileOK. A
comment for 2.2:
"If the document's MIME type, as specified in the HTTP response
Content-Type header, is not application/vnd.wap.xhtml+xml or
application/xhtml+wml , FAIL"
These are called Internet Media Types (rather than MIME I think) and are
not registered. Are you planning to register them?
I am not an expert but am checking to see if mobileOK requires XHTML
Basic and Basic requires application/xhtml+xml.
"If the document's DOCTYPE's PUBLIC identifier is not an XHTML
Basic identifier (at present, "-//W3C//DTD XHTML Basic 1.1//EN" or
"-//W3C//DTD XHTML Basic 1.0//EN"), FAIL"
In case the references help, the topic came up in March of 2004 on two
different W3C lists [2,3].
[1] http://www.w3.org/TR/2006/WD-mobileOK-20060712/
[2] http://lists.w3.org/Archives/Public/www-validator/2004Mar/0001
[3] http://lists.w3.org/Archives/Public/www-archive/2004Mar/0000
Hope this helps,
Related issues: (space separated ids)
WG Notes: I responded that we'll fix the doc accordingly on 7/28, and did in the next draft.
Resolution: Fixed per comment. (Please make sure the resolution is adapted for public consumption)
Add a comment .