[minutes] F2F Day 3 - 27 March 2009 - CT HTTPS, Korean TF, Addendum, Accessibility, Checker from Francois Daoust on 2009-03-30 (public-bpwg@w3.org from March 2009)

From: Francois Daoust <fd@w3.org>
Date: Mon, 30 Mar 2009 15:27:34 +0200
To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
Message-ID: <49D0C8C6.4040909@w3.org>

Hi,

The minutes of the third day of last week's F2F are available at:
http://www.w3.org/2009/03/27-bpwg-minutes.html
... and copied as text below.

Here is a more readable summary of things that were discussed during the
day. Many thanks to Adam and Google for hosting the F2F!

The last day of the F2F started with a discussion on HTTPS links
rewriting in the context of Content Transformation and more generally on
whether a two-party consent model is required or not in this particular
use case. The Korean task force reported on the mobileOK trial service
run in South Korea. The Addendum to the Mobile Web Best Practices was
amended to take comments sent to the mailing-list into account. Rigo
presented the updated version of the mobileOK license. Yeliz and Alan
reported on the advancement of the WCAG/MWBP document. I mentioned the
upcoming changes in the mobileOK Checker library before we closed the
meeting and the F2F.

Content Transformation - HTTPS links rewriting
-----
- The Internet Architecture Board, in its recommendations about
chartering OPES in the IETF, does not require two-party consent. It
requires one-party consent, but notes that, by itself, it is not enough
to protect data integrity.
- There is no strong consensus in the working group on the topic as to
whether two-party consent is required in the case of HTTPS connections
where only the server is authenticated via an SSL certificate.
- The working group eventually agreed on the following resolution:
Interception of HTTPS and the circumstances in which it might be
permissible is not a "mobile" question, as such, but is highly pertinent
to our document. We are aware that interception of HTTPS happens in the
network today. We think that interception of HTTPS is inherently
problematic and may be unsafe. We'd like to refer to more general
conformance criteria to protocol based signalling mechanisms to achieve
this. Pending futher developments in this area the practice of
intercepting HTTPS links is strongly NOT RECOMMENDED.

Korean Task Force report
-----
Seungyun and Jonathan reported on the mobileOK trial run in South Korea,
and on the first results on the gap analysis between the Mobile Web Best
Practices and the Korean market.

The working group resolved to accept regional and other elaborations and
derivations of mobileOK. Checkers which implement such derivations
SHOULD provide the ability to check W3C mobileOK in addition to the
derivation. The names of such derivations need to be considered further
to avoid possible confusion, misinterpretation W3C licensing terms, or
trademarks.

Addendum to the Mobile Web Best Practices
-----
- Comments sent to the mailing-list were reviewed, and Kai was actioned
to amend the text where needed.
- An editorial meeting on the addendum is to take place on Friday
morning (EU timezone), see:
http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0169.html

mobileOK License
-----
Rigo presented the updated mobileOK license, and responded to the
questions that were raised during our previous F2F in Mandelieu. Jo is
to review the license and update the few minor points that need to be
updated in the Scheme document before we publish both documents.

Relationship between WCAG and MWBP
-----
The group thanks Yeliz and Alan for their hard work on the
"Relationship" document and we officially endorse sending it (including
above text from Yeliz) over to WAI EO for final review and launch.

Upcoming changes to the mobileOK Checker library
-----
I am to work on the changes to bring more flexibility to the library,
and in particular the possibility to add support for the "file" scheme
as a plug-in without having to change the core code of the library. I
hope to be able to do that in the next two weeks.

Thanks,
Francois.

-----
27 Mar 2009

[2]Agenda

[2]
http://www.w3.org/2005/MWI/BPWG/Group/Meetings/London3/logistics.html

See also: [3]IRC log

[3] http://www.w3.org/2009/03/27-bpwg-irc

Attendees

Present
Jonathan, Seungyun, Eduardo, Kai, Rob, DKA, Jo, francois,
SeanP, yeliz, achuter, Rigo_on_the_phone

Regrets
none

Chair
DKA

Scribe
Kai, EdC, rob, francois, Jo

Contents

The day started with a revision of the group's position on the issue
of HTTPS for the [4]Guidelines for Web Content Transformation
Proxies specification, followed by a report of the Korean Task
force, a short editorial meeting on the [5]Addendum to the Mobile
Web Best Practices specification, a review of the updated mobileOK
license with Rigo, a review of the remaining work on the
[6]Relationship between Mobile Web Best Practices (MWBP) and Web
Content Accessibility Guidelines (WCAG) specification, and a short
report on the mobileOK Checker library.
* [7]Topics
1. [8]CT - OPES and two-party consent (reprise)
2. [9]Korean Task Force report
3. [10]Addendum to Mobile Web Best Practices
4. [11]mobileOK License (with Rigo)
5. [12]Mobile / Accessibility Roundup
6. [13]Upcoming changes to the mobileOK Checker library
7. [14]Thanks
* [15]Summary of Action Items

[4]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/0090313
[5]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20090210
[6]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/ED-mwbp-wcag-20090218/

Minutes of the F2F

* [16]Day 1/3
* [17]Day 2/3
* [18]Day 3/3 (this page)
_________________________________________________________

[16] http://www.w3.org/2009/03/25-bpwg-minutes.html
[17] http://www.w3.org/2009/03/26-bpwg-minutes.html
[18] http://www.w3.org/2009/03/27-bpwg-minutes.html

CT - OPES and two-party consent (reprise)

<Jo> ISOC Position

<Jo> The Internet Architecture Board (IAB) has made the following
recommendations about chartering OPES in the IETF:

<Jo> An OPES framework standardized in the IETF must require that
the use of any OPES service be explicitly authorized by one of the
application-layer end-hosts (that is, either the content provider or
the client). For an OPES framework standardized in the IETF, the
OPES intermediary must be explicitly addressed at the IP layer by
the end user. The overall OPES framework needs to assist content...

<Jo> ...providers in detecting and responding to client-centric
actions by OPES intermediaries that are deemed inappropriate by the
content provider. The overall OPES framework should assist end users
in detecting the behavior of OPES intermediaries, potentially
allowing them to identify imperfect or compromised intermediaries.
If there exists a "non-OPES" version of content available from
the...

<Jo> ...content provider, the OPES architecture must not prevent
users from retrieving this "non-OPES" version from the content
provider. OPES documentation must be clear in describing these
services as being applied to the result of URI resolution, not as
URI resolution itself. All proposed services must define their
impact on inter- and intra-document reference validity. The overall
OPES...

<Jo> ...framework must provide for mechanisms for end users to
determine the privacy policies of OPES intermediaries.

[displaying a OPES text on one party consent]

DKA: the origin server needs to approve the third party presence
... with the model we discussed yesterday the origin server can deny
but not approve

<Jo> --> [19]http://www.isoc.org/briefings/005/ OPES Briefing by
ISOC

[19] http://www.isoc.org/briefings/005/

DKA: the implicitly approve unless they actively deny
... but they can, the CP has the power to do so

<Jo> One-party consent, with one of the end-hosts explicitly
authorizing the OPES service, must be a requirement for OPES to be
standardized in the IETF. However, the one-party consent model by
itself (e.g., with one of the end-hosts authorizing the OPES
service, and the other end- host perhaps being unaware of the OPES
service) is insufficient for protecting data integrity in the
network. We...

<Jo> ...also agree with others that, regardless of the security and
authorization mechanisms standardized for OPES in the IETF, OPES
implementations could probably be modified to circumvent these
mechanisms, resulting in the unauthorized modification of content.
Still, this is true of many protocols considered by the IETF, and by
itself should not represent a compelling reason not to
standardize...

<Jo> ...transport protocols, routing protocols, web caching
protocols, or OPES itself. Instead, the infrastructure needs, as
much as possible, to be designed to detect and defend itself against
compromised implementations, and misuses of protocols need to be
addressed directly, each in the appropriate venue.

DKA: how can the CP signal to the chain of what he wishes to do?
... to avoid unwanted modification of any sort

Jo: i think there is difference between this and no-transform
... on the web 'weblike' things will happen. Here the CP needs to
clearly confirm that the modification is ok

DKA: so this is in the security context and therefore different

EdC: so must have an opt in rather than an opt out mechanism

SeanP: i think as in Skyfire the expectations are changing

DKA: I agree
... if i were a bank I would feel the same about opera mini as I
would about this situation
... so if we say opera mini is ok then this is ok.

EdC: you cannot generalize
... given liabilities, agreements etc. it might be ok, but you
cannot generalize

DKA: but we cannot stop the banks from using the occuring practice
... if we say that W3C compliant intermediate proxies must not
change https, then we know this will not be honored
... CT proxies will transform anyway. It makes it ambiguous and
banks won't know how to deal with it or won't know if the proxy does
not send the via header

Jo: no, we are saying if it is a conforming proxy it will not happen

EdC: you are saying we can want

DKA: we are saying if they see a via header there is a proxy

EdC: so far the assumption is there is one connnection that is not
broken and you are reversing it

DKA: we are telling them the truth

EdC: if this is valid it is also valid for the fixed internet

SeanP: if we allow https transform you are saying that opera mini is
wrong

Jo: opera mini is directly used by the user because it is part of
the environment

rob: well the user choose vodafones CT

DKA: what if there is an agreement between the client and the CT

rob: contractually banks say that is the users liability

EdC: there is precendence. financial institution started to use
their own wap gateways due to security concerns

Jo: I agree with EdC. we are rolling back history here

DKA: we are giving the bank the option
... anybody has the opportunity to redirect the user to a mobile
friendly version that has no security problems

francois: actually you can't because the session is already
established

Jo: the CT proxy vendors have been with us for a long time, so full
respect, but less principled ones will try to defeat the principles
... there is an absolutist position we must adopt. What is required
is what we cannot provide. A robust regime for consent by whichever
parties in this.
... if it is more common then it is needed urgently. It is not for
us to invent new mechanisms.

SeanP: that seems like a good compromise
... they"ll know there is a proxy in the loop, due to via

EdC: why should content server change?

Jo: perhaps we should request something for http 1.2
... this is simply not in scope for us

DKA: if that is so that does lead to what we have resolved. We must
say that it is not possible to transform , err, not compliant. this
means we must remain silent.

Jo: I don't think we can remain silent. We must be clear on whether
we endorse what has been happening.

DKA: we don't have strong consensus on this point
... and it was not an original goal and so we don't have to make a
strong point

francois: we don't have consensus on the topic

DKA: [who will raise formal objections depending on the options]

Jo: I would be happy with one party consent if the one party were
the CP

[discussion and presentation of options and their normative
character]

DKA: options are

<Jo> PROPOSED RESOLUTION 1: Make no reference to HTTPS

DKA: no normative statement on transforming https content

<Jo> PROPSOED RESOLUTION 2: Say that Intercepting HTTPS is
permissible only with the CP's consent

DKA: conforming CT must not transform http content without express
consent of the origin server

<Jo> PROPOSED RESOLUTION 3: Interception of HTTPS is permissible if
the CP has an opportunity to refuse it

DKA: conforming proxies may transform https without consent of the
origin server under certain circumstances
... e.g. express consent by the user

Can we truly make normative statemenss, knowing that there is no
technology to solve the problem at hand

EdC: look at what this means for the mobile community

Kai..refering to the OPES text which says the infrastructure needs
to take care of security

<DKA> PROPOSED RESOLUTION: on the matter of https, we should have no
normative statement but instead refer readers to the OPES briefing
from ISOC on this point.

<DKA> PROPOSED RESOLUTION: on the matter of transforming of https,
we should have no normative statement but instead refer readers to
the OPES briefing from ISOC on this point.

<DKA> PROPOSED RESOLUTION: on the matter of transforming of https
content, we should have no normative statement but instead refer
readers to the OPES briefing from ISOC on this point.

SeanP: the OPES stuff applies to more that just httpS
... this invalidates the entire transformation thing

francois: it is just about security

SeanP: this looks like a general statement

rob: opes says is insufficient for protection data in the net
... so it is true, but doesn't say that you shouldn't do it

DKA: how about the proposals I made

rob: we could say that origin server consent is mandatory or not

Trying to see what this would look like from the CP side

scribe: I am worried about the legal angle of it. will the CP be
held responsible as we are for links on page we link to.

DKA: if somebody uses this document ot set up a w3c compliant CT
proxy solution in their network
... if we know in room that current operation who are requesting CT
proxies, are asking the to transform https content, they will not
use this document...we will have not impact
... so we can be all fuzzy about it, but it will be an empty
document
... it doesn't meet the requirements of what is happening today.

so we should state the problem and why it cannot be solved, offer
the best solutions possible and make it all non normative

We will not solve this right now, but we need to make it possible to
fix things later down the line

<DKA> PROPOSED RESOLUTION: on the matter of transforming of https
content, we should have no normative statement requiring consent of
origin server but we should have informative text on the statement
of the proble, the reason for the problem and guidance for solving
the problem.

<EdC> -1

<SeanP> +1

<francois> -1

<rob> +1

<DKA> +1

<achuter> +0

<Jo> PROPOSED RESOLUTION: Interception of HTTPS and the
circumstances in which it might be permissible is not a "mobile"
question, as such, but is highly pertinent to our document. We are
aware that interception of HTTPS happens in the network today. We
think that interception of HTTPS is inherently problematic and may
be unsafe. We'd like to refer to more general conformance criteria
to HTTPS....

<Jo> ...We're not aware of any conformance criteria or "good
practice" in respect of this subject. We'd liek also to see positive
consent mechanisms around this. We think that ultimately such
positive consent mechansims are the onloyt satisfactory way of
addressing this issue, We're not aware of any such mechanisms.

<Jo> -1

<Jo> (to Dan's)

What if we combine these and add option what can be done to Jo's
text

francois: what will you then put into the document?

Jo: input by somebody competent in this subject
... we could also say that this is bad practice
... edc do you agree that it is broader than mobile

EdC: yes. we have asked for input and were told to leave it alone
... cps set up the certificates and now we say we are doing
something else now

<Jo> ...We're not aware of any conformance criteria or "good
practice" in respect of this subject. We'd like also to see positive
consent mechanisms around this. We think that ultimately such
positive consent mechansims are the onlyt satisfactory way of
addressing this issue. We're not aware of any such mechanisms.
Pending futher developments in this area the practice of
intercepting HTTPS links...

<Jo> ...is strongly NOT RECOMMENDED.

EdC: just because some operators are interested in doing something
we are saying we don't want to have the most authorized party in the
chain to give their consent

DKA: if we keep strongly worded recommendations in here, that is not
a good practice

we should put in all the options of what you can do to make it
better

<Jo> ...HTTPS.We're not aware of any conformance criteria in respect
of this subject. We have sought and are aware of various good
practice statements that indicate strongly that this is bad
practice. We'd like to see positive consent mechanisms around this.
We think that ultimately such positive consent mechansims are the
only satisfactory way of addressing this issue. We're not aware of
any...

<Jo> ...such mechanisms. Pending futher developments in this area
the practice of intercepting HTTPS links is strongly NOT
RECOMMENDED.

<DKA> +1

+1 proviso that we explain which good practices exist

<Jo> ...protocol based signalling mechanisms to achieve this.
Pending futher developments in this area the practice of
intercepting HTTPS links is strongly NOT RECOMMENDED.

<DKA> +1

<EdC> -1

+1 proviso that we explain which good practices exist

<rob> +1

<SeanP> 0

Jo: What is your point, Eduardo?

<francois> [20]RFC2119

[20] http://www.ietf.org/rfc/rfc2119.txt

EdC: what does it mean in terms of the normative level?
... so is the valid reason that we want to do it?

Jo: no, you must state the reasons why and part of this are the
conformance considerations

<francois> +1

<achuter> +0

<JonathanJ> +0

<Jo> 0

<yeliz> +0

[discussion with Eduardo regarding his -1]

RESOLUTION: Interception of HTTPS and the circumstances in which it
might be permissible is not a "mobile" question, as such, but is
highly pertinent to our document. We are aware that interception of
HTTPS happens in the network today. We think that interception of
HTTPS is inherently problematic and may be unsafe. We'd like to
refer to more general conformance criteria to protocol based
signalling mechanisms to achieve this. Pending futher developments
in this area the practice of intercepting HTTPS links is strongly
NOT RECOMMENDED.

<Kai> PRPOPOSED RESOLUTION: all known methods to improve the
situation of consent and common understanding of the risks involved,
as well as mechanisms to minimize those risks, should be spelled out
as examples for improving potential https content transformation if
it is being used

<DKA> Information on the Twiggy mobile widget:
[21]http://twiggy.carsonified.com/

[21] http://twiggy.carsonified.com/

<JonathanJ> [22]http://tinyurl.com/djaoeu <-- Our WidgetCamp page
(using google translator)

[22] http://tinyurl.com/djaoeu

<rob> +1

<SeanP> +1

Jo: put the topic on the side. Seems contradictory with the previous
resolution. Require more details on how user consent is achieved.

Kai: rephrase in the form of possibilities as areas for other groups
to investigate.

Sean: this would be a purely informative statement.

Francois: mention explicitly via header field.

<Jo> PROPOSED RESOLUTION: make sure that relevant points are called
out in conformance statement and point out to content providers in
Appendix D that via headers in HTTPS sessions need to be examined
carefully

Kai: do not require user consent, as this is not a normative
statement.
... why limit this to the via header field? What about whitelists?

Jo: Whitelists are not statements on the content provider.
Previously we resolved not to talk about them.

Sean: they are actually mentioned in the introduction of the CTG.

Kai: put as much concrete information as possible about how to
improve the situation.

Sean: via, user consent, whitelist.

Jo: what about disallow lists?
... we must move on to other topics.

Kai: what do we do with the resolution?

<DKA> +1 on Kai's proposal

<Jo> -1 to taking either PROPOSED RESOLUTION as stands they both
need further discussion

Kai: informative statements should be explicit.

-2 as Jo. Postpone.

<Kai> +1 to mine

DKA: postpone the discussion.

Francois: let's raise an issue.

<Kai> ISSUE: all known methods to improve the situation of consent
and common understanding of the risks involved, as well as
mechanisms to minimize those risks, should be spelled out as
examples for improving potential https content transformation if it
is being used

<trackbot> Created ISSUE-294 - All known methods to improve the
situation of consent and common understanding of the risks involved,
as well as mechanisms to minimize those risks, should be spelled out
as examples for improving potential https content transformation if
it is being used ; please complete additional details at
[23]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/294/edit .

[23] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/294/edit

<francois> s/Francois let's/Francois: let's/

<Jo> ISSUE: it is impossible to reconcile pragmatism and expediency
with good practice

<trackbot> Created ISSUE-295 - It is impossible to reconcile
pragmatism and expediency with good practice ; please complete
additional details at
[24]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/295/edit .

[24] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/295/edit

Korean Task Force report

<JonathanJ> [25]http://docs.google.com/Doc?id=ddkw3489_108hqrnvkgs

[25] http://docs.google.com/Doc?id=ddkw3489_108hqrnvkgs

Seung-Yun: reports on the Korea task force.

<JonathanJ> Gap analysis :
[26]http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0162.htm
l

[26] http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0162.html

seungyun: two documents produced (mobile svc in Korea, gap analysis
between Korea and W3C).
...
... Forum about developing standards aligned with W3C. Currently,
mostly harmonized. Proof of concept of applicability of these
standards by developing a trial application.
... We developed basic environment: common DDR server, content
validator, browser simulator, and a portal.
... server (details in the document linked above). Portal with two
versions (mobile and desktop).
... DDR server independent from mobile operator (neutral, own DDR
server). Specific functions for Korea (e.g. pivot) supported.

<JonathanJ> mobileOK portal in Korea : [27]http://www.mobileok.kr

[27] http://www.mobileok.kr/

<JonathanJ> K-mobileOK validator : [28]http://v.mobileok.kr

[28] http://v.mobileok.kr/

seungyun: implements mobileOk 1.0 and K-DDC 1.5 (some differences
with W3C). Several ways to tag the trustmark.

Jo: How does Javascript trustmark work?

Jonathan: a script (copy-pasted SCRIPT invocation) generates the
logo on the terminal. Demonstrates with m.zdnet.co.kr.

seungyun: extended mobile browser simulator, specially for
smartphones. Based on previous WIPI platform, but also Winmobile.
Runs on WinXP/Vista. Looks like a typical generic (not-phone
specific) browser simulator.

<JonathanJ> K-mobileOK validator (in english, using google
translator) : [29]http://tinyurl.com/d9n8g9

[29] http://tinyurl.com/d9n8g9

seungyun: the mobile portal provides information about mobileOK. The
mobile version is generic for all phones.
... deployment of the portal was accompanied by events. Interest in
adapting web sites according to mobileOK.
... more reference mobileOK-conformant content needed to go beyond
proof of concept.
... few guides to develop according to mobileOK.
... Korea has its own standards, which differ somewhat from the W3C
ones. Besides, some relevant W3C work is not completed.
... many Korean companies are eagerly waiting for best practices and
guides about developing mobile applications (in the line of MWBP).
... goal is for large-scale mobileOK web service and dissemination
actions. Extensions are considered as well for m-e-commerce
(payment).
... the points of future plan are listed in the aforementioned
document. Application perspective is the main orientation.

DKA: Is this a web based payment system.

Seungyun: I'm not an expert, but it is based on web technology.

DKA: We need to see Jonathan's presentation and we need to see where
your work fits into the working group and need to have a discussion.

Jo: We need to see the GAP analysis.
... How will you gather the information for the DDR?

DKA: Let's here the information from Jonathan.

Jonathan: Gap Analysis between W3C MWBP and Korean community
... I will be brief since it is not complete.
... After previous TPAC, I made some modifications to this document.
... I will explain the updates.
... Discussion of the new gaps: COOKIE_AUTOFILL; mentioned in K-MWBP
1.5, not in W3C
...NAVBAR_CONSISTENCY: mentioned in K-MWBP 1.5, not W3C
... CONTENT_NAVBAR_DESIGN; mentioned in K-MWBP 1.5, not W3C
... NAVBAR_EXPANSION, MULTI_WINDOW_SUPPORT, AJAX_SUPPORT,
PAGE_SIZE_ALERT, SUPPORT_SCRIPT, IMAGE_SIZE_ADJUST, ALERT_IMAGE (all
in K-MWBP 1.5, not W3C)
... IMAGES_LENGTH_UNIT (should use pixels, but no restriction)

Jo: Why is that?

Jonathan: Vendor requirement.

Jo: Pixels are used so we know how big the image will be when the
page is laid out (so it isn't laid out twice)

DKA: Everything before looked OK, up to here, and this kind of
contradicts what MWBP says.

Kai: I think they are talking about different kinds of units, not no
units.

Jonathan: MEASURES_UNIFY, MIME_TYPE

Jo: So the META element is require for MIME type?

Jonathan: Vendor requirement.

Jo: ... could be a difference between what HTTP and META says.

Jonathan: I agree.
... COOKIES APPLICATION, FONTS_SUPPORT, FONT_DEFAULT,
FONT_USAGE_LIMIT (all in K-MWBP 1.5, not W3C)
... COOKIES_APPLICATION is in MWABP.
... Details on COOKIE_AUTOFILL (Desired ACTION: Consider for MWABP)

[Looking at a MWBP with the new Korean BP's added]

DKA: The JavaScript requirement sounds like a requirement on the
device.

Jonathan: ECMAscript is required on the device.

DKA: Do you require a particular version of ECMAscript. Are you
requiring CPs to use ECMASCRIPT?

Jonathan: If they use ECMAscript they must use 1.5.

DKA: You are saying this document (Korean MWBP) is being edited and
there is a meeting in April? So we can point out where we agree and
disagree?

Jo: There are a number of comments and some more understanding that
needs to take place.
... It looks like you have done a lot of work. What are are saying
there is not such thing as a basic phone in Korea? No phones without
JS?

Kai: I think this is going away from mobileOK as intended. The DDC
is the minimum device that can handle the web. The DDC as defined
for Korea is more the device we wish to see.
... I would be surprised if this is the simplest device in Korea.
What happens to people who have more basic phones?
... If CP's follow these recommendations, people with basic phones
won't be able to access the content.
... The DDC is very basic. I think you have raised the level too
much. There are also a lot of vendor specific requirements in there.
Vendors follow their own agenda and standards are a secondary issue.
... I'm not sure where this leads us.

Jo: I think it is OK for Korea to have a different baseline than the
rest of the world. What the the w3c is trying to do is address the
whole world.

Kai: The problem is mobileOK is worldwide standard, and the Korean
one is different. Which one do people follow?

Jo: Korean mobileOK has a different goal. I don't think that it
would be OK to have a UK or USA mobileOK.

Seungyun: Not necessary to have one DDC.
... we couldn't always meet the requirements of the DDC, for example
page size. It is is not necessary to have one profile.

<DKA> PROPOSED RESOLUTION: the group accepts the idea of regional
variation to the DDC.

Seungyun: DDC 1.0 is not available all over the world, especially
Korea. We propose a profile approach. It depends on the
country--they can have their own DDC.

Kai: Jo has a point. If there is a Korean somewhere in the world and
has a DDC phone. Can he view the Korean content?

Jonathan: Do they have Korean character set?

DKA: This is a philosophical argument.

Kai: My point is that there will be confusion because there are
multiple mobileOK's.

Jonathan: Two level system: Korean and W3C mobileOK.

DKA: The checker will say not mobileOK for DDC, but mobileOK for
Korean market, right?

Kai: Isn't it about adapting pages? The server should serve up
content that fits the device, even for a DDC device.

Jo: It is reasonable to say that CPs can develop content only for
phones they want. We tell them to exploit device capabilities.

Kai: No we say exploit device capabilities, but need to serve
something for less capable devices.

<DKA> If a Korean page is MobileOK but is loaded into a device with
no Korean chacater set, can anyone perceive it?

Jo: it is pointless to, for example, create iPhone apps that work on
the DDC.

Kai: Missing the point. What Korea needs is in the W3C mobileOK.

Jo: it is perfectly OK for Korea to define their own mobileOK. It is
OK to develop large pages for example to exploit the large memories,
etc.

PROPOSED RESOLUTION: the group accepts the idea of regional
variation to the DDC.

DKA: The idea of a regional variation of the DDC makes sense, but
I'd like to see guidance to other efforts that are creating regional
variations, but inform CPs that their content is W3C mobileOK or
not.
... then they've got the option to either do Korean mobileOK or W3C
mobileOK.

Jo: This is a slippery subject.
... the resolution as put is not correct.

DKA: We're not going to actually take this resolution.

Jo: What is our attitude to aspirational rewards?
... There is one DDC; it is confusing to add a Korean DDC; should be
called something else.

<DKA> PROVOCATIONAL RESOLUTION: the group accepts the idea of
regional additions to the DDC.

Jo: I support rewarding people for exploiting device capabilities.
... mobileOK is about saying that content is OK for low end devices.
... there should be an aspirational level. This is what the Korean
work does.

Kai: There is a basic misunderstanding about the DDC. This is all
possible under the DDC. A Korean page would not necessarily adapt to
the DDC. You could still develop are really good page that exploits
device capabilities.

DKA: This is burdonsome to the Korean market.

Kai: Burdonsome to us too.

DKA: It may not make any sense for the Korean market since they have
a different baseline.

Seungyun: mobileOK only supports the basic phone, right?

DKA: You can detect the phone and send content based on the
capabilities of the phone.
... the CP still needs to support the baseline device.

Seungyun: People want to see better content. People think the DDC
restricts content.

Kai: No it doesn't. Only for a really basic phone.

Seungyun: But the checker will fail.

Kai: No the checker only checks if the content will adapt to the
device.

Jo: You could say that if content is advertised as Korean mobileOK
and not mobileOK, then that is warning.

<JonathanJ> I have an practical question. which group user is lager
or larger using mobile web ? feature phone user in the world or
iPhone/smartphone users ? I think it was become practical and
important issue today.

<DKA> PROVOCATIONAL RESOLUTION: the group accepts the idea of
regional variations to MobileOK (for example K-MobileOK). Any
conformant MobileOK checker which implements such a variation
(validating content against for example K-MobileOK tests) must also
inform the content provider of the MobileOK-ness of the content.

Jo: DDC has nothing to do what is in the market.

<seungyun> +1

Kai: We have mobileOK as a baseline. If you want to go beyond that,
it is OK.

DKA: But that isn't useful in the Korean market.

Kai: We have a basic misunderstanding of the DDC.

DKA: There is a misunderstanding in the whole world. It may be our
fault.

Kai: Korea can be mobileOK. The only requirement is that they adapt
to basic devices. Doesn't prevent them from doing great content.
... the name is a problem.

<Jo> PROPOSED RESOLUTION: ANy derivatives of the idea should avoid
calling themselves mobileOK or DDC

Seungyun: I think I do understand mobileOK. The problem is very
small. DDC should be changed in the future. Status of Korea: from
our perspective it is not something we want to create for.

<JonathanJ> I think if we stay in restricted base line, our mobileOk
cannot support advance feature in mobile web world. It's really
important issue.

<DKA> I suggest K-MobileOK is sufficiently different a name from
MobileOK to allow for this.

<Jo> coming back to Jonathan's earlier point: I have an practical
question. which group user is lager or larger using mobile web ?
feature phone user in the world or iPhone/smartphone users ? I think
it was become practical and important issue today.

Kai: You say the average device is more sophisticated than the DDC,
but mobileOK is a worldwide standard. You can still create
sophisticated content--you just need to adapt to basic devices.

DKA: You are creating a set of tests; additional checker routines,
etc.
... is it acceptable for you for the Korean checker to also report
on the baseline mobileOK as well as the Korean mobileOK?

Jo: There would need to be two completely different tests.

Seungyun: You can already choose the type of test you want to have.
... You have the option of picking either KmobileOK or regular
mobileOK.

<JonathanJ> what about good mobile web site that made for iphone,
can they get mobileOK trustmark ? currently, it's impossible.

DKA: No problem then. I don't think regional variations need a
different name.

Yeliz: Are other countries required to create their own mobileOK's.

Kai: I think that a clearer name would be good to make it clear that
this is different level.

<DKA> PROVOCATIONAL RESOLUTION: the group accepts the idea of
regional variations to MobileOK (deferring judgement on what these
should be named to avoid confusion). Any conformant MobileOK checker
which implements such a variation (validating content against for
example K-MobileOK tests) must also allow the content provider to
validate against vanilla W3C MobileOK.

Jo: I think naming something that is an aspirational level
differently than the baseline level would be good.

Kai: This is not an aspirational level, it is the Korean baseline
level.
... I agree, except it is not a variation of mobileOK.

DKA: It is a variation.

<JonathanJ> We have two level in DDC. K-DDC 1.0 is totally same W3C
DDC in MWBP, K-DDC 1.5 just include some advanced feature.

Jo: We need to defer the question of naming. Since the KmobileOK
contradicts some of mobileOK, it should have a different name.

DKA: [definition of variation]

<Kai> PROVOCATIONAL RESOLUTION: the group accepts the idea of
regional variations on the sophistication in the adaptability of web
sites (deferring judgement on what these should be named to avoid
confusion). Any conformant MobileOK checker which implements such a
variation (validating content against for example K-MobileOK tests)
must also allow the content provider to validate against vanilla...

<Kai> ...W3C MobileOK.

DKA: I'm talking about the document; a variation of that.

<Kai> PROVOCATIONAL RESOLUTION: the group accepts the idea of
regional variations in sophistication of websites (deferring
judgement on what these should be named to avoid confusion). Any
conformant MobileOK checker which implements such a variation
(validating content against for example K-MobileOK tests) must also
allow the content provider to validate against vanilla W3C MobileOK.

<DKA> [pause for reflection]

<Jo> PROPOSED RESOLUTION: The working group accepts regional and
other elaborations and modifications of mobileOK. Checkers which
implement such altered versions of mobileOK SHOULD provide the
ability to check W3C mobileOK in addition to the variant. The names
of such variants need to be considered further to avoid possible
confusion or misinterpretation.

Jo: This resolution doesn't require HTTP; could work on files.

<DKA> +1

Francois: What about ready.mobi; is that a form of mobileOK?

<DKA> +1 already

Yeliz: Regarding the file definition; isn't that different. With
files it is a partial test; isn't this different in this case?

<Kai> -1 because we are not changing mobileOK. We accept that
regionally it may be required to support more than mobileOK, but
does not mean that a web site does not ALSO have to be able to serve
DDC content.

Jo: We'd like to keep families of tests together.

Francois: Are stepping into copyright problems? mobileOK is
copyrighted.

<JonathanJ> +1

DKA: We're talking about doing this in the working group. We need to
accept it here.
... we can't allow people to fork the spec since it is not in the
copyright.

<SeanP> +1 to Jo's resolution

francois: we can ask Rigo on the phone this afternoon

DKA: we don't need that

jo: what wording needs to change?

Kai: we are not modifying mobileOK

<JonathanJ> We are already discussed about francois's point.

DKA: so just say derivations

<JonathanJ> Korean mobileOK policy :
[30]http://www.dt.co.kr/contents.html?article_no=2009031702010631699
002

[30]
http://www.dt.co.kr/contents.html?article_no=2009031702010631699002

<Jo> PROPOSED RESOLUTION: The working group accepts regional and
other elaborations and derivations of mobileOK. Checkers which
implement such derivations SHOULD provide the ability to check W3C
mobileOK in addition to the derivation. The names of such
derivations need to be considered further to avoid possible
confusion, misinterpretation W3C licensing terms, or trademarks

<Jo> .

<JonathanJ>
[31]http://docs.google.com/Doc?docid=dhpvgnmn_61fhktmzfq&hl=ko

[31] http://docs.google.com/Doc?docid=dhpvgnmn_61fhktmzfq&hl=ko

<DKA> +1

<JonathanJ> s/ Korean mobileOK policy :
[32]http://www.dt.co.kr/contents.html?article_no=2009031702010631699
002//

[32]
http://www.dt.co.kr/contents.html?article_no=2009031702010631699002//

<DKA> +1 from SeanP

<seungyun> +1

<Jo> +1

<JonathanJ> +1

<yeliz> +1

<Kai> +1 provided the name of the derivation does not contain
mobileOK

RESOLUTION: The working group accepts regional and other
elaborations and derivations of mobileOK. Checkers which implement
such derivations SHOULD provide the ability to check W3C mobileOK in
addition to the derivation. The names of such derivations need to be
considered further to avoid possible confusion, misinterpretation
W3C licensing terms, or trademarks.

<achuter1> +1

<Jo> ACTION: Dan to lead discussion on list on Korean mobileOK
proposals [recorded in
[33]http://www.w3.org/2009/03/27-bpwg-minutes.html#action01]

<trackbot> Created ACTION-935 - Lead discussion on list on Korean
mobileOK proposals [on Daniel Appelquist - due 2009-04-03].

DKA: So i'll take the discussion forward about how we take Korean
mobileOK forward formally

Addendum to Mobile Web Best Practices

<Kai>
[34]http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/dra
fts/ED-mobileOK-pro10-tests-20090210

[34]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20090210

Kai: Looking at the results of the questionnaire
... there are a few typos we'll correct later

<achuter1>
[35]http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0009.htm
l

[35] http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0009.html

achuter1: The section on Relevant Device Properties, are these
properties that have to be detected?

Kai: no, we're not limiting ourselves to properties that can be
detected

achuter1: there's no explanation of what the sections "Relevant
Device Properties" means

Kai: that's what I had and it was changed because the group didn't
like it

<Jo> PROPOSED RESOLUTION: Include an explanatory section under the
introduction to explain what the sections of the statements mean

<Kai> p

<Kai> PROPOSED RESOLUTION: for the purpose of this document relevant
device properties means properties which are affected by the
evaluations

Kai: we can still add an explanatory section except that we did
scrap a section that described the evaluation format because we
don't follow the same format for every evaluation nowadays

achuter1: If it's only the properties that's ambiguous can we insert
the clarification somewhere else?

Kai: Do we need it or not?
... I think not

DKA: ok, it stays out

Kai: Jo reformulated the original texts in 1.1. Don't really want to
change them back again
... 1.2 Relationship to mobileOK Tests and the paragraph that
doesn't seem to fit. What do we do about that?

francois: I liked the abstract's text
... it's more positive text about improving UX on more capable
devices

achuter1: Surely these evalucations are not about advanced devices,
only about tests that can't be automated?

[Jo proposes revised text on screen]

<Jo> jo is working on
[36]http://docs.google.com/Edit?id=dgh5r6zs_34ds9nt6kh

[36] http://docs.google.com/Edit?id=dgh5r6zs_34ds9nt6kh

Jo: some limits need to be parameterised, as we discussed this
morning with W3C DDC vs Korean DDC?

Kai: shouldn't we just rephrase the sentence in a more positive
fashion

<Jo> ACTION: Kai to re-write 1.2 in a more happy clappy way
[recorded in
[37]http://www.w3.org/2009/03/27-bpwg-minutes.html#action02]

<trackbot> Created ACTION-936 - Re-write 1.2 in a more happy clappy
way [on Kai Scheppe - due 2009-04-03].

<Jo> ACTION: Kai to correct spelling errors [recorded in
[38]http://www.w3.org/2009/03/27-bpwg-minutes.html#action03]

<trackbot> Created ACTION-937 - Correct spelling errors [on Kai
Scheppe - due 2009-04-03].

<Jo> ACTION: kai to correct last paragraph of 1.2 - it doesn't have
"tests" and Best PRactices should read mobileOK Basic Tests
[recorded in
[39]http://www.w3.org/2009/03/27-bpwg-minutes.html#action04]

<trackbot> Created ACTION-938 - Correct last paragraph of 1.2 - it
doesn't have \"tests\" and Best PRactices should read mobileOK Basic
Tests [on Kai Scheppe - due 2009-04-03].

Kai: In 2.1, my feeling is WCAG isn't referenced for good reason

achuter1: yes, I agree

<Jo> ACTION: Kai to replace example in section 3.4 with an image (as
it doesn't print etc.) [recorded in
[40]http://www.w3.org/2009/03/27-bpwg-minutes.html#action05]

<trackbot> Created ACTION-939 - Replace example in section 3.4 with
an image (as it doesn't print etc.) [on Kai Scheppe - due
2009-04-03].

achuter1: In 3.4 reference for colour-blindness isn't required
because there is a test for contrast

<Jo> ACTION: Kai to provide a reference to the Ishigara Colour
Blindness test [recorded in
[41]http://www.w3.org/2009/03/27-bpwg-minutes.html#action06]

<trackbot> Created ACTION-940 - Provide a reference to the Ishigara
Colour Blindness test [on Kai Scheppe - due 2009-04-03].

<Jo> ACTION: Kai to add a refernce to the algorithm for determining
contrast [recorded in
[42]http://www.w3.org/2009/03/27-bpwg-minutes.html#action07]

<trackbot> Created ACTION-941 - Add a refernce to the algorithm for
determining contrast [on Kai Scheppe - due 2009-04-03].

Kai: I know we used an algorithm to calculate contrast, I'll find
that reference again
... Thanks Alan for those comments.
... Onto Francois's

francois: Section 2.1 Evaluation scope, what's this for?

Kai: because some tests refer to single pages, some to multiple
pages
... but we can drop it

<Jo> ACTION: Kai to drop section 2. And maybe insert an explanatory
section on the layout of the evaluations (to maintain numbering)
[recorded in
[43]http://www.w3.org/2009/03/27-bpwg-minutes.html#action08]

<trackbot> Created ACTION-942 - Drop section 2. And maybe insert an
explanatory section on the layout of the evaluations (to maintain
numbering) [on Kai Scheppe - due 2009-04-03].

<Jo> ACTION: Kai to rephrase 3.15 ref tables [recorded in
[44]http://www.w3.org/2009/03/27-bpwg-minutes.html#action09]

<trackbot> Created ACTION-943 - Rephrase 3.15 ref tables [on Kai
Scheppe - due 2009-04-03].

<Kai> ACTION: kai to drop 4. in 3.17 [recorded in
[45]http://www.w3.org/2009/03/27-bpwg-minutes.html#action10]

<trackbot> Created ACTION-944 - Drop 4. in 3.17 [on Kai Scheppe -
due 2009-04-03].

Rob: sec 3.17 the <font face="..."> attribute wasn't standard

Kai: ok, we'll delete that bullet

<Kai> ACTION: Kai to move 3.18 Note into examples [recorded in
[46]http://www.w3.org/2009/03/27-bpwg-minutes.html#action11]

<trackbot> Created ACTION-945 - Move 3.18 Note into examples [on Kai
Scheppe - due 2009-04-03].

Kai: on 3.26 page title this 2nd bullet is to catch people using
copy-and-paste to create pages
... who forget to give pages meaningful titles

<Kai> ACTION: Kai to add bandwidth to device properties in 3.30
[recorded in
[47]http://www.w3.org/2009/03/27-bpwg-minutes.html#action12]

<trackbot> Created ACTION-946 - Add bandwidth to device properties
in 3.30 [on Kai Scheppe - due 2009-04-03].

francois: so if you do have multiple pages of linear content we
should have titles like "Results List (1/12)"

Kai: yes

francois: 3.34 table layout my main point is don't recommend a hack
against a gap in the technology

Kai: I can rephrase this

Jo: I can send an example of how to do this

<Jo> ACTION: Jo to send Kai an example of 3 col layout where column
balance is maintained [recorded in
[48]http://www.w3.org/2009/03/27-bpwg-minutes.html#action13]

<trackbot> Created ACTION-947 - Send Kai an example of 3 col layout
where column balance is maintained [on Jo Rabin - due 2009-04-03].

<Kai> ACTION: kai to rephrase 3.34 to not call for table layout and
propose CSS based solution as in DTAG [recorded in
[49]http://www.w3.org/2009/03/27-bpwg-minutes.html#action14]

<trackbot> Created ACTION-948 - Rephrase 3.34 to not call for table
layout and propose CSS based solution as in DTAG [on Kai Scheppe -
due 2009-04-03].

Kai: Thanks Francois for those
... Onto Eduardo's comments
... We started with this layout and the group didn't like it so
we're not moving back to the old layout
... with regard other to General remarks, these are evaluations not
best practices now
... and a roadmap is out-of-scope.
... In detailed observations, these are npt prescriptive and are in
no particular order.

Jo: are there dependencies between them that imply an order?

Kai: not particularly, no

yeliz: if there are dependencies, should the evaluations be combined
into one?

Kai: we've completely removed any regidity in the document format.
But there is a sequence, you do run these evaluations in order.

jo: for example 3.37 "Ensure that" is clear, "Check if" isn't.

Kai: This is editorial as far as I am concerned. Give me an action
and I'll do it.

Jo: What I had hoped for was an editorial session but we've failed
to find face-to-face time for that
... It'd still be a good idea to have an editorial meeting, even
remotely via Google Docs

<Kai> ACTION: kai to change access to access keys in 3.1 [recorded
in [50]http://www.w3.org/2009/03/27-bpwg-minutes.html#action15]

<trackbot> Created ACTION-949 - Change access to access keys in 3.1
[on Kai Scheppe - due 2009-04-03].

Kai: section 3.9 I don't see what's unfortunate about the language

achuter1: Fogg is just an example, there are others that are not
English-only

Kai: This is only an example, it's clear

Jo: We have precident for final editorial meetings after which
there's very limited change

<Jo> [something about jerking remnants of goo]

DKA: when can we do this?

Jo: We'll set an afternoon aside

Kai: 3.14 bullets 3 and 4 do seem to be the same

<francois> ACTION: Kai to remove bullet 4 in 3.14 [recorded in
[51]http://www.w3.org/2009/03/27-bpwg-minutes.html#action16]

<trackbot> Created ACTION-950 - Remove bullet 4 in 3.14 [on Kai
Scheppe - due 2009-04-03].

Kai: 3.30 checks *all* CSS is used in every page

Rob: didn't we say this evaluation could apply to whole sites?

Jo: we also can't use *all* the media-selectors

Kai: I'll propose revised text

<francois> ACTION: kai to propose some text on 3.30 ref. *all* CSS
for next editorial session [recorded in
[52]http://www.w3.org/2009/03/27-bpwg-minutes.html#action17]

<trackbot> Created ACTION-951 - Propose some text on 3.30 ref. *all*
CSS for next editorial session [on Kai Scheppe - due 2009-04-03].

Kai: Thanks Eduardo for those points
... Overall the changes are quite minor, so I'll issue a new draft
before the editorial session
... then at that point this document will be done!

DKA: so what date for the editorial meeting?
... how about April 3?

Jo: 8:00-11:00 UK time?

Kai: ok, 09:00-12:00 CET

Jo: we'll edit it on Google Docs

mobileOK License (with Rigo)

->
[53]http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Trustmark/
20081114.html W3C mobileOK scheme latest draft

[53]
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Trustmark/20081114.html

->
[54]http://www.w3.org/Consortium/Legal/2008/04-mobileok-policy.html
mobileOK license

[54] http://www.w3.org/Consortium/Legal/2008/04-mobileok-policy.html

->
[55]http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0168.htm
l Questions and responses on the mobileOK license

[55] http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0168.html

[quick round around the table to introduce participants]

Dan: We were just starting to review the document, and our lists of
questions on mobileOK

<Jo> -->
[56]http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0168.htm
l REFERNCE DOC

[56] http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0168.html

Jo: Let's just step through this, shouldn't take long.
... Under 1, done, wonderful.
... Under 2, you're staying on "icon", right?

<Jo> ACTION: Jo to remove the word trustmark from scheme document
[recorded in
[57]http://www.w3.org/2009/03/27-bpwg-minutes.html#action18]

<trackbot> Created ACTION-952 - Remove the word trustmark from
scheme document [on Jo Rabin - due 2009-04-03].

rigo: trustmark has a specific meaning, so I would strongly
recommend that you do not use it in the Scheme document.
... There are implications around quality.
... "Icon" is more neutral.

jo: agreed.

rigo: note it's just a recommendation, I could live with
"trustmark", just think it's better to have "icon" in there.

jo: We had a question about URIs and IRIs. Done, thank you.
... Number 4: what constitutes a claim for conformance?

rigo: I tried a definition in 2.1.
... It mainly is a phrase with certain variables.
... [reading text in section 2.1 of the policy]
... I should probably add 2.3 as well next to 2.2 in that text.
... If you claim a URI is mobileOK, then following 2.2 and 2.3, none
of the tests defined in mobileOK Basic Tests must fail.
... If you have a bunch of URIs, then you are making an assertion
that each one of these URIs is mobileOK.
... Those are the conditions to use the trademark or the icon.
... If some tests of mobileOK Basic Tests 1.0 fail, then you are not
granted the license, and if you use the trademark or icon, then
that's a violation.

jo: we need to have a technical discussion within the group as to
how claim mobileOK-ness on a Web site.

rigo: you don't need to update the text of the policy to do that.

jo: OK, I think that's clear. I just think we need to think
technically what we need by a Web site, i.e. if we include the
infinity of addresses of a Web site that do not exist.

rigo: you have to realize that you cannot test anything on
non-existing stuff.
... so you should include it.

jo: OK. I think we have a discussion to conduct within the group
about the time when the claim is made, i.e. whether it means a URI
will be mobileOK in the future or not.

rigo: it's not only technical, you have to think about the
marketing.
... The closer you match with the assertions you're making and the
tests that can be made to assert the validity of the assertion, the
better the marketing will be.
... The question is: how do you identify the portion of the site
that is mobileOK?

jo: OK, thank you. Let's move on to 5.
... You just dealt with.
... So, question 6.
... About the use of the mobileOK string outside of a claim.

dan: Isn't that an example of fair use?

rigo: it's not even fair use. As long as you do not use mobileOK in
a commercial context that misrepresent the trademark and the origin
of the trademark, then you are fine.
... You can use it, say it's crap, discuss it.
... In very private stuff, it may not be so clear, but I don't think
we should care.

jo: [going through the rest of the questions 7,8,9,10,11,12,13. All
done]
... Question 14 on the link associated with the logo.

rigo: yes, we had the problem before, because the logo for the
markup validator was on our site, and you had to use a URI on W3C
servers, but the resulting load was huge.
... you may have a link to the mobileOK Checker, provided there's a
"referer" functionality.

dan: Do we want to say something about that? I don't think so.

rigo: dom and francois could talk to Olivier to have the
functionality in the mobileOK Checker.
... Legally, it's not a problem, we can require it, or suggest it.

jo: On to the final point, which was actually the starting point a
long time ago
... The question is: using mobileOK on a page that is not itself
mobileOK is just fine provided you make it clear.

rigo: Not even that.
... You can make an assertion on TV, buses, or whatever.

jo: The confusion comes in when you have example.com serve different
content depending on the device that requests it.
... You'd like to claim mobileOK-ness even if the URI does not
return mobileOK content for a given mobile device.

rigo: that's covered.

jo: I understand your point. Now that 2.2 contains "dereferenced in
the manner described", it makes it a lot clearer and removes the
problem.

rigo: next steps: a minor change to the license. As soon as your
scheme doc is ready, we can launch!

<DKA> PROPOSED RESOLUTION: The working group approves and endorses
the MobileOK License and empowers W3C team to launch it.

<Jo> ACTION: Jo to edit mobileOK scheme appropriately to discussion
with Rigo at London F2F [recorded in
[58]http://www.w3.org/2009/03/27-bpwg-minutes.html#action19]

<trackbot> Created ACTION-953 - Edit mobileOK scheme appropriately
to discussion with Rigo at London F2F [on Jo Rabin - due
2009-04-03].

<DKA> PROPOSED RESOLUTION: The working group thanks Rigo his work on
the MobileOK License and hereby approves and endorses the MobileOK
License and empowers W3C team to launch it.

[The group thanks rigo!]

<DKA> +1

<rob> +1

<DKA> Kai: +1

<seungyun> +1

<yeliz> +1

jo: I'd like to review the text before. I think the first sentence
should read: "The members of W3C has developed" for instance.

<DKA> PROPOSED RESOLUTION: The working group thanks Rigo his work on
the MobileOK License which we, pending Jo's review, will launch with
all speed.

<DKA> +1

<rob> +1

<scribe> ACTION: jo to review the final mobileOK license for
approval during next BPWG call [recorded in
[59]http://www.w3.org/2009/03/27-bpwg-minutes.html#action20]

<trackbot> Created ACTION-954 - Review the final mobileOK license
for approval during next BPWG call [on Jo Rabin - due 2009-04-03].

RESOLUTION: The working group thanks Rigo his work on the MobileOK
License which we, pending Jo's review, will launch with all speed.

[break]

<DKA> [60]http://oreilly.com/catalog/9780596518738/

[60] http://oreilly.com/catalog/9780596518738/

Mobile / Accessibility Roundup

tigger: last item on the agenda

eeyore: suggest we ask for an update

<achuter1>
[61]http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/d
rafts/ED-mwbp-wcag-20090218/

[61]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/ED-mwbp-wcag-20090218/

alan: The accessibility doc is nearly finished, being reviewed by
EOWG

<achuter1> In principle, both WCAG and MWBP aim to improve the Web
interaction

<achuter1> of users who experience barriers due to either
disabilities or the

<achuter1> device used to access the Web. However, WCAG and MWBP
have slightly

<achuter1> different approaches. For instance, even though WCAG in
some

<achuter1> countries is a legal requirement, MWBP is not. Although
some best

<achuter1> practices are testable in MWBP, testability is a key
feature of the

<achuter1> WCAG 2.0 principles. However, despite these differences,
they both

<achuter1> focus on user experience.

alan: one more thing to be included ...
... and once included will go to WCAG WG

PROPOSED RESOLUTION: BPWG agrees to inclusion of the above text from
Yeliz

<rob> +1

dka: question on text
... we don't want to rule out mobileOK ness
... as a legal requirement
... and it could happen there was some talk about it - yada yada

rob: replace not with not necessarily

alan: both try to improve the user experience
... could be phrased in terms of usability effects

dka: both focus on ...

alan: don't require user testing

yeliz: improving user experience?

[assent to this idea]

dka: text goes where?

yeliz: overview page

<yeliz> In principle, both WCAG and MWBP aim to improve the Web
interaction of users who experience barriers due to either
disabilities or the device used to access the Web. However, WCAG and
MWBP have slightly different approaches. For instance, even though
WCAG in some countries is a legal requirement, MWBP is not
necessarily a legal requirement. Although some best practices are
testable in MWBP, testability is a key feature of the WCAG 2.0
principles. However, despite

[these differences, they both focus on user experience.]

alan: actually it got a lot shorter than last time it was reviewed

jo: shall we review it now?

[reviewing on screen]

<DKA> PROPOSED RESOLUTION: The group thanks Yeliz and Alan for their
hard work on the "Relationship" document and we officially endorse
sending it over to WAI EO for final review and launch.

<DKA> PROPOSED RESOLUTION: The group thanks Yeliz and Alan for their
hard work on the "Relationship" document and we officially endorse
sending it (including above text from Yeliz) over to WAI EO for
final review and launch.

<rob> +1

+1 to Yeliz and +1 to Alan

+1 to launching too

<DKA> +1

<DKA> +4

<achuter1> +1

RESOLUTION: The group thanks Yeliz and Alan for their hard work on
the "Relationship" document and we officially endorse sending it
(including above text from Yeliz) over to WAI EO for final review
and launch.

alan: there is another document we have forgotten about till now

dka: does it make sense to have another document, doesn't the shared
web experiences cover it?

yeliz: what is this document, was it created before I joined the
group?

<achuter1>
[62]http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/d
rafts/ED-mwbp-wcag-helps-20080612/

[62]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/ED-mwbp-wcag-helps-20080612/

[sounds of Alan typing]

Dan: [losing his marbles] david, shirley, what?
... let's call it a day. If there is anything left over we can
reconsdier following Alan's research.

<scribe> ACTION: Alan to review whether there really is anything
that needs bringing forward from the earlier doc [recorded in
[63]http://www.w3.org/2009/03/27-bpwg-minutes.html#action21]

<trackbot> Created ACTION-955 - Review whether there really is
anything that needs bringing forward from the earlier doc [on Alan
Chuter - due 2009-04-03].

Upcoming changes to the mobileOK Checker library

Francois: we didn't talk about mobileOK checker
... I invetigated what ti would take to change mobileOK checker so
it becomes more flexible
... and it would be nice if we could make it flexible so you could
add tests etc.
... it's possible to do this and it would benefit the library as a
whole
... send my results to mobileOK-checker mailing list
... everyone seemed fine with it and I get to implement the changes
... and then we can do things like support of the file: URI
extensions

dka: is Koprea using the same base

francois: yes they forked our code but it's not open source yet
... they haven't released the source code

dka: would your changes help them?

francois: yes

dka: we should encourage them to move over to the next version

alan: could it be done in XML

francois: for now it is a kind of hybrid
... not planning to do it right now
... actually maybe I will
... to be clear, if there are projects out there that use the
library they'd have to change a bit
... i.e. the changes won't be backwards compatible
... there are projects other than the Korean one that use the
library

yeliz: released as a new version?

francois: yes, new libaray we won't fork and won't maintain old
version
... that's it?

yeliz: what is the timeframe

francois: mid april I expect
... but that may not be very accurate

yeliz: my project is coming to an end

francois: I will start next week
... you could start work on the XSLT tests
... the tests need to be redefined
... cannot tell etc.

yeliz: jo wasn't keen on cannot tell
... overall result will be CANNOTTELL if not HTTP

francois: the library doens't say mobileOK anyway

jo: mumbles

francois: I'll proceed and report when it is done

Thanks

PROPOSED RESOLUTION: Many thanks to Google and Adam for arranging it
for their tremendous hospitality

<achuter1> +1

<rob> +1

<francois> +1

<DKA> +1

RESOLUTION: Many thanks to Google and Adam for arranging it for
their tremendous hospitality

[meeting adjourned]

Summary of Action Items

[NEW] ACTION: Alan to review whether there really is anything that
needs bringing forward from the earlier doc [recorded in
[64]http://www.w3.org/2009/03/27-bpwg-minutes.html#action21]
[NEW] ACTION: Dan to lead discussion on list on Korean mobileOK
proposals [recorded in
[65]http://www.w3.org/2009/03/27-bpwg-minutes.html#action01]
[NEW] ACTION: Jo to edit mobileOK scheme appropriately to discussion
with Rigo at London F2F [recorded in
[66]http://www.w3.org/2009/03/27-bpwg-minutes.html#action19]
[NEW] ACTION: Jo to remove the word trustmark from scheme document
[recorded in
[67]http://www.w3.org/2009/03/27-bpwg-minutes.html#action18]
[NEW] ACTION: jo to review the final mobileOK license for approval
during next BPWG call [recorded in
[68]http://www.w3.org/2009/03/27-bpwg-minutes.html#action20]
[NEW] ACTION: Jo to send Kai an example of 3 col layout where column
balance is maintained [recorded in
[69]http://www.w3.org/2009/03/27-bpwg-minutes.html#action13]
[NEW] ACTION: Kai to add a refernce to the algorithm for determining
contrast [recorded in
[70]http://www.w3.org/2009/03/27-bpwg-minutes.html#action07]
[NEW] ACTION: Kai to add bandwidth to device properties in 3.30
[recorded in
[71]http://www.w3.org/2009/03/27-bpwg-minutes.html#action12]
[NEW] ACTION: kai to change access to access keys in 3.1 [recorded
in [72]http://www.w3.org/2009/03/27-bpwg-minutes.html#action15]
[NEW] ACTION: kai to correct last paragraph of 1.2 - it doesn't have
"tests" and Best PRactices should read mobileOK Basic Tests
[recorded in
[73]http://www.w3.org/2009/03/27-bpwg-minutes.html#action04]
[NEW] ACTION: Kai to correct spelling errors [recorded in
[74]http://www.w3.org/2009/03/27-bpwg-minutes.html#action03]
[NEW] ACTION: kai to drop 4. in 3.17 [recorded in
[75]http://www.w3.org/2009/03/27-bpwg-minutes.html#action10]
[NEW] ACTION: Kai to drop section 2. And maybe insert an explanatory
section on the layout of the evaluations (to maintain numbering)
[recorded in
[76]http://www.w3.org/2009/03/27-bpwg-minutes.html#action08]
[NEW] ACTION: Kai to move 3.18 Note into examples [recorded in
[77]http://www.w3.org/2009/03/27-bpwg-minutes.html#action11]
[NEW] ACTION: kai to propose some text on 3.30 ref. *all* CSS for
next editorial session [recorded in
[78]http://www.w3.org/2009/03/27-bpwg-minutes.html#action17]
[NEW] ACTION: Kai to provide a reference to the Ishigara Colour
Blindness test [recorded in
[79]http://www.w3.org/2009/03/27-bpwg-minutes.html#action06]
[NEW] ACTION: Kai to re-write 1.2 in a more happy clappy way
[recorded in
[80]http://www.w3.org/2009/03/27-bpwg-minutes.html#action02]
[NEW] ACTION: Kai to remove bullet 4 in 3.14 [recorded in
[81]http://www.w3.org/2009/03/27-bpwg-minutes.html#action16]
[NEW] ACTION: Kai to rephrase 3.15 ref tables [recorded in
[82]http://www.w3.org/2009/03/27-bpwg-minutes.html#action09]
[NEW] ACTION: kai to rephrase 3.34 to not call for table layout and
propose CSS based solution as in DTAG [recorded in
[83]http://www.w3.org/2009/03/27-bpwg-minutes.html#action14]
[NEW] ACTION: Kai to replace example in section 3.4 with an image
(as it doesn't print etc.) [recorded in
[84]http://www.w3.org/2009/03/27-bpwg-minutes.html#action05]

[End of minutes]

Received on Monday, 30 March 2009 13:28:21 UTC