BPWG F2F, London March 2009, Day 3/3 -- 27 Mar 2009

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> --> http://www.isoc.org/briefings/005/ OPES Briefing by ISOC

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

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: http://twiggy.carsonified.com/

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

<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 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 http://www.w3.org/2005/MWI/BPWG/Group/track/issues/295/edit .

Korean Task Force report

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

Seung-Yun: reports on the Korea task force.

<JonathanJ> Gap analysis : 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 : http://www.mobileok.kr

<JonathanJ> K-mobileOK validator : 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) : 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 : 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> http://docs.google.com/Doc?docid=dhpvgnmn_61fhktmzfq&hl=ko

<DKA> +1

<JonathanJ> s/ Korean mobileOK policy : 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 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> 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> 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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)

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

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

-> http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0168.html Questions and responses on the mobileOK license

[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> --> http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0168.html REFERNCE DOC

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 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 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 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> http://oreilly.com/catalog/9780596518738/

Mobile / Accessibility Roundup

tigger: last item on the agenda

eeyore: suggest we ask for an update

<achuter1> 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> 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 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]

BPWG F2F London March 2009, Day 3/3

27 Mar 2009

Attendees

Contents

Minutes of the F2F

CT - OPES and two-party consent (reprise)

Korean Task Force report

Addendum to Mobile Web Best Practices

mobileOK License (with Rigo)

Mobile / Accessibility Roundup

Upcoming changes to the mobileOK Checker library

Thanks

Summary of Action Items