List of comments on “W3C mobileOK Scheme 1.0” (dated 12 July 2006)

Status: allopen proposal pending resolved_yes resolved_no resolved_partial other Type: allsubstantive editorial typo question general comment undefined

Quick access to LC-1464 LC-1465 LC-1466 LC-1467 LC-1468

Comment LC-1464

Commenter: Susan Lesch <lesch@w3.org> (archived message)

Context: 1.4.3 Visual Representation

Status:

open proposal pending resolved_yes resolved_no resolved_partial other assigned to Nobody

Type: substantive editorial typo question general comment undefined

Comment:

n the mobileOK 1.0 draft, label [1] appears to be the source of
authenticity. Have you considered a lightweight text-based logo styled
in CSS? From 1.4.3 Visual Representation [2]:

"Content which bears a mobileOK label may optionally advertise this
by displaying a mobileOK logo (to be produced)..."

The example below condensed is about 200 bytes. A CSS expert can improve
on that no doubt. :-). I don't know if the mobileOK mark is meant to be
a service mark, or a trademark or if the strings would need to be
protected by patent, copyright or trade or service mark registration.
Apologies in advance if I misunderstood, and the spec means that the
logo itself needs to be hard to forge.

<a id="mobileOK"
href="http://www.example.com/mobileOK/#id4485358">mobileOKâ„¢</a>

a#mobileOK {
margin-left: 0;
padding: 0.05% 0.3%;
background: #fff;
color: #093;
text-decoration: none;
font: bold smaller sans-serif;
}

[1] http://www.w3.org/TR/mobileOK/#id4477838
[2] http://www.w3.org/TR/mobileOK/#id4485358

Related issues: (space separated ids)

WG Notes: (Following up for the tracker) I replied on 7/28 with the following. If anything, the open question is whether to supply both an image and CSS-styled logo in the final labels spec later. "If the final mobileOK logo is substantially just text, then I agree that an alternate CSS version could useful. I am not sure if the W3C has guidelines or policies on this but it sounds reasonable to me. I am not a lawyer, though I suspect the term "mobileOK" will have the usual appropriate set of legal protections. We will make sure that the appropriate marks appears on the logo. The logo itself does not necessarily need to be hard to forge, but rather the machine-readable label -- you read it right. Thanks as always, Sean"

Resolution:

(Please make sure the resolution is adapted for public consumption)

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 disposition
Commenter'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)

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 disposition
Commenter'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 disposition
Commenter'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 disposition
Commenter'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)