W3C home > Mailing lists > Public > public-bpwg@w3.org > March 2009

[minutes] F2F Day 3 - 27 March 2009 - CT HTTPS, Korean TF, Addendum, Accessibility, Checker

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

    +1

    <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> 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 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> 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...

    <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> 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...

    <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> ...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

    <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.

    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

    +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

    +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

    +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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 March 2009 13:28:21 GMT