09:34:15 RRSAgent has joined #bpwg 09:34:15 logging to http://www.w3.org/2009/03/27-bpwg-irc 09:34:18 Zakim has joined #bpwg 09:34:28 RRSAgent, make logs public 09:35:08 Agenda: http://www.w3.org/2005/MWI/BPWG/Group/Meetings/London3/logistics.html 09:35:19 Jo has joined #bpwg 09:35:43 Meeting: BPWG F2F London March 2009, Day 3 09:36:10 Chair: DKA 09:36:29 Present: Jonathan, Seungyun, Eduardo, Kai, Rob, DKA, Jo, francois 09:38:54 EdC has joined #bpwg 09:39:03 Present+ SeanP 09:40:39 scribenick: edc 09:40:58 DKA has joined #bpwg 09:40:59 scribenick: kai 09:41:27 Kai has joined #bpwg 09:42:12 Topic: OPES (reprise) 09:42:21 ISOC Position 09:42:23 The Internet Architecture Board (IAB) has made the following recommendations about chartering OPES in the IETF: 09:42:24 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... 09:42:26 ...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... 09:42:27 ...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... 09:42:30 ...framework must provide for mechanisms for end users to determine the privacy policies of OPES intermediaries. 09:44:09 SeanP has joined #bpwg 09:44:22 scribe:Kai 09:48:19 [displaying a OPES text on one party consent] 09:48:50 DKA: the origin server needs to approve the third party presence 09:49:09 RRSAgent, draft minutes 09:49:09 I have made the request to generate http://www.w3.org/2009/03/27-bpwg-minutes.html francois 09:49:15 ...with the model we discussed yesterday the origin server can deny but not approve 09:49:27 --> http://www.isoc.org/briefings/005/ OPES Briefing by ISOC 09:49:44 ...the implicitly approve unless they actively deny 09:49:56 ...but they can, the CP has the power to do so 09:49:58 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... 09:50:00 ...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... 09:50:01 ...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. 09:50:22 DKA: how can the CP signal to the chain of what he wishes to do? 09:50:43 ...to avoid unwanted modification of any sort 09:51:00 Jo: i think there is difference between this and no-transform 09:52:04 ...on the web 'weblike' things will happen. Here the CP needs to clearly confirm that the modification is ok 09:52:59 DKA: so this is in the security context and therefore different 09:53:30 EdC: so must have an opt in rather than an opt out mechanism 09:53:50 SeanP: i think as in sky fire the expectations are changing 09:53:54 DKA: I agree 09:54:17 ...if i were a bank I would feel the same about opera mini as I would about this situation 09:54:29 ...so if we say opera mini is ok then this is ok. 09:54:37 EdC: you cannot generalize 09:54:57 ...given liabilities, agreements etc. it might be ok, but you cannot generalize 09:55:17 DKA: but we cannot stop the banks from using the occuring practice 09:56:07 ...if we say that W3C compliant intermediate proxies must not change https, then we know this will not be honored 09:56:53 ...CT proxies will transform anyway. It makes it amiguous and banks won't know how to deal with it or won't know if the proxy does not send the via header 09:57:16 Jo: no, we are saying if it is a conforming proxy it will not happen 09:57:41 s/amiguous/ambiguous 09:57:55 EdC: you are saying we can want 09:58:17 DKA: we are saying if they see a via header there is a proxy 09:58:38 EdC: so far the assumption is there is one connnection that is not broken and you are reversing it 09:58:43 DKA: we are telling them the truth 09:58:59 EdC: if this is valid it is also valid for the fixed internet 09:59:32 SeanP: if we allow https transform you are saying that opera mini is wrong 09:59:53 Jo: opera mini is directly used by the user because it is part of the environment 10:00:06 rob: well the user choose vodafones CT 10:00:24 DKA: what if there is an agreement between the client and the CT 10:00:46 rob: contractually banks say that is the users liability 10:01:34 EdC: there is precendence. financial institution started to use their own wap gateways due to security concerns 10:01:54 Jo: I agree with EdC. we are rolling back history here 10:02:02 DKA: we are giving the bank the option 10:02:35 ...anybody has the opportunity to redirect the user to a mobile friendly version that has no security problems 10:02:52 francois: actually you can't because the session is already established 10:03:39 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 10:04:46 achuter has joined #bpwg 10:05:00 ...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. 10:05:31 ...if it is more common then it is needed urgently. It is not for us to invent new mechanisms. 10:05:45 SeanP: that seems like a good compromise 10:05:59 ...they"ll know there is a proxy in the loop, due to via 10:06:21 EdC: why should content server change? 10:06:45 Jo: perhaps we should request something for http 1.2 10:06:59 ...this is simply not in scope for us 10:07:34 yeliz has joined #bpwg 10:07:54 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. 10:08:53 Jo: I don't think we can remain silent. We must be clear on whether we endorse what has been happening. 10:09:30 DKA: we don't have strong consensus on this point 10:09:52 ...and it was not an original goal and so we don't have to make a strong point 10:10:17 francois: we don't have consensus on the topic 10:10:53 DKA: [who will raise formal objections depending on the options] 10:11:19 Jo: I would be happy with one party consent if the one party were the CP 10:14:37 [discussion and presentation of options and their normative character] 10:15:44 DKA: options are 10:15:52 PROPOSED RESOLUTION 1: Make no reference to HTTPS 10:16:00 ...no normative statement on transforming https content 10:16:20 PROPSOED RESOLUTION 2: Say that Intercepting HTTPS is permissible only with the CP's consent 10:16:34 ...conforming CT must not transform http content without express consent of the origin server 10:17:13 PROPOSED RESOLUTION 3: Interception of HTTPS is permissible if the CP has an opportunity to refuse it 10:17:21 ...conforming proxies may transform https without consent of the origin server under certain circumstances 10:17:58 ...e.g. express consent by the user 10:19:29 Can we truly make normative statemenss, knowing that there is no technology to solve the problem at hand 10:21:05 EdC: look at what this means for the mobile community 10:23:03 RRSAgent, draft minute 10:23:03 I'm logging. I don't understand 'draft minute', francois. Try /msg RRSAgent help 10:23:11 RRSAgent, draft minutes 10:23:11 I have made the request to generate http://www.w3.org/2009/03/27-bpwg-minutes.html francois 10:23:15 Kai..refering to the OPES text which sazs the infrastructure needs to take care of security 10:23:38 Present+ yeliz, achuter 10:23:54 s/sazs/says/ 10:24:00 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. 10:24:14 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. 10:24:23 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. 10:25:19 SeanP: the OPES stuff applies to more that just httpS 10:25:51 ...this invalidates the entire transformation thing 10:26:08 francois: it is just about security 10:26:34 SeanP: this looks like a general statement 10:27:10 rob: opes says is insufficient for protection data in the net 10:27:37 ..so it is true, but doesn't say that you shouldn't do it 10:27:58 DKA: how about the proposals I made 10:29:15 rob: we could say that origin server consent is mandatory or not 10:32:32 Trying to see what this would look like from the CP side 10:32:57 ...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. 10:33:48 s/..so it/...so it/ 10:34:02 DKA: if somebody uses this document ot set up a w3c compient CT proxy solution in their network 10:34:43 ...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 wil have not impact 10:35:02 ...so we can be all fuzzy about it, but it will be an empty document 10:35:46 ...it doesn't meet the requirements of what is happening today. 10:36:46 so we should state the problem and why it cannot be solved, offer the best solutions possible and make it all non normative 10:37:34 We will not solve this right now, but we need to make it possible to fix things later down the line 10:38:09 s/w3c compient/w3c compliant/ 10:38:29 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. 10:38:32 s/we wil have/we will have/ 10:38:45 +1 10:38:48 -1 10:38:50 +1 10:38:53 -1 10:38:55 +1 10:38:59 +1 10:39:01 +0 10:39:16 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.... 10:39:18 ...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. 10:39:19 -1 10:39:25 (to Dan's) 10:41:52 What if we combine these and add option what can be done to Jo's text 10:42:27 francois: what will you then put into the document? 10:42:43 Jo: input by somebody competent in this subject 10:43:00 q? 10:44:16 Jo: we could also say that this is bad practice 10:44:35 ..edc do you agree that it is broader than mobile 10:44:55 EdC: yes. we have asked for input and were told to leave it alone 10:45:30 ...cps set up the certificates and now we say we are doing something else now 10:46:00 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.... 10:46:02 ...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... 10:46:04 ...is strongly NOT RECOMMENDED. 10:46:10 ...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 10:46:32 DKA: if we keep strongly worded recommendations in here, that is not a good practice 10:49:14 we should put in all the options of what you can do to make it better 10:51:23 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... 10:51:25 ...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... 10:51:26 ...such mechanisms. Pending futher developments in this area the practice of intercepting HTTPS links is strongly NOT RECOMMENDED. 10:53:05 +1 10:54:15 +1 proviso that we explain which good practices exist 10:54:49 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... 10:54:51 ...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... 10:54:53 ...protocol based signalling mechanisms to achieve this. Pending futher developments in this area the practice of intercepting HTTPS links is strongly NOT RECOMMENDED. 10:55:11 +1 10:55:25 -1 10:55:30 +1 proviso that we explain which good practices exist 10:55:34 +1 10:55:49 0 10:56:13 Jo: What is your point, Eduardo? 10:56:36 -> http://www.ietf.org/rfc/rfc2119.txt RFC2119 10:56:37 EdC: what does it mean in terms of the normative level? 10:57:40 ...so is the valid reason that we want to do it? 10:58:12 Jo: no, you must state the reasons why and part of this are the security considerations 10:58:50 s/security/conformance/ 11:00:46 +1 11:00:51 +0 11:00:54 +0 11:00:55 0 11:01:00 +0 11:02:38 [discussion with Eduardo regarding his -1] 11:05:17 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...and further 11:05:36 RESOLUTION: 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...and... 11:05:37 ...further 11:05:56 RESOLUTION: ...protocol based signalling mechanisms to achieve this. Pending futher developments in this area the practice of intercepting HTTPS links is strongly NOT RECOMMENDED. 11:08:17 Scribe: EdC 11:11:51 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 11:14:36 Information on the Twiggy mobile widget: http://twiggy.carsonified.com/ 11:20:26 achuter1 has joined #bpwg 11:22:05 http://tinyurl.com/djaoeu <-- Our WidgetCamp page (using google translator) 11:27:40 achuter1 has joined #bpwg 11:29:59 +1 11:30:08 +1 11:30:47 Jo: put the topic on the side. Seems contradictory with the previous resolution. Require more details on how user consent is achieved. 11:31:19 Kai: rephrase in the form of possibilities as areas for other groups to investigate. 11:31:29 Sean: this would be a purely informative statement. 11:32:24 François: mention explicitly via header field. 11:32:30 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 11:32:37 Kai: do not require user consent, as this is not a normative statement. 11:33:21 Kai: why limit this to the via header field? What about whitelists? 11:33:52 Jo: Whitelists are not statements on the content provider. Previously we resolved not to talk about them. 11:34:03 Sean: they are actually mentioned in the introduction of the CTG. 11:34:37 Kai: put as much concrete information as possible about how to improve the situation. 11:34:52 Sean: via, user consent, whitelist. 11:35:33 Jo: what about disallow lists? 11:35:52 Jo: we must move on to other topics. 11:36:11 q? 11:36:26 Kai: what do we do with the resolution? 11:36:53 +1 on Kai's proposal 11:36:54 -1 to taking the resolution either PROPOSED RESOLUTION as stands they both need further discussion 11:37:00 Kai: informative statements should be explicit. 11:37:11 -2 as Jo. Postpone. 11:37:20 +1 to mine 11:37:25 DKA: postpone the discussion. 11:37:38 s/the resolution// 11:37:45 François let's raise an issue. 11:37:56 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 11:37:57 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 . 11:38:14 s/Francois let's/Francois: let's/ 11:38:30 ISSUE: it is impossible to reconcile pragmatism and expediency with good practice 11:38:30 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 . 11:38:40 Topic: Korean Task Force report 11:38:51 http://docs.google.com/Doc?id=ddkw3489_108hqrnvkgs 11:39:02 Seung-Yun: reports on the Korea task force. 11:39:47 Gap analysis : http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0162.html 11:39:51 seungyun: two documents produced (mobile svc in Korea, gap analysis between Korea and W3C). 11:39:59 ... 11:40:53 ... Forum about developing standards aligned with W3C. Currently, mostly harmonized. Proof of concept of applicability of these standards by developing a trial application. 11:41:40 seungyun: We developed basic environment: common DDR server, content validator, browser simulator, and a portal. 11:43:47 seungyun: server (details in the document linked above). Portal with two versions (mobile and desktop). 11:45:19 seungyun: DDR server independent from mobile operator (neutral, own DDR server). Specific functions for Korea (e.g. pivot) supported. 11:45:29 mobileOK portal in Korea : http://www.mobileok.kr 11:45:44 K-mobileOK validator : http://v.mobileok.kr 11:46:17 seungyun: implements mobileOk 1.0 and K-DDC 1.5 (some differences with W3C). Several ways to tag the trustmark. 11:46:35 Jo: What does Javascript trustmark work? 11:49:56 Jonathan: a script (copy-pasted SCRIPT invocation) generates the logo on the terminal. Demonstrates with m.zdnet.co.kr. 11:50:10 s/What/How/ 11:51:38 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. 11:52:44 K-mobileOK validator (in english, using google translator) : http://tinyurl.com/d9n8g9 11:53:50 seungyun: the mobile portal provides information about mobileOK. The mobile version is generic for all phones. 11:54:50 seungyun: deployment of the portal was accompanied by events. Interest in adapting web sites according to mobileOK. 11:55:22 seungyun: more reference mobileOK-conformant content needed to go beyond proof of concept. 11:55:40 seungyun: few guides to develop according to mobileOK. 11:56:23 seungyun: Korea has its own standards, which differ somewhat from the W3C ones. Besides, some relevant W3C work is not completed. 11:57:16 seungyun: many Korean companies are eagerly waiting for best practices and guides about developing mobile applications (in the line of MWBP). 11:58:39 seungyun: goal is for large-scale mobileOK web service and dissemination actions. Extensions are considered as well for m-e-commerce (payment). 11:59:45 seungyun: the points of future plan are listed in the aforementioned document. Application perspective is the main orientation. 12:00:02 Scribenick: SeanP 12:00:18 DKA: Is this a web based payment system. 12:00:40 Seungyun: I'm not an expert, but it is based on web technology. 12:01:42 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. 12:01:53 Jo: We need to see the GAP analysis. 12:02:10 Jo: How will you gather the information for the DDR? 12:03:46 DKA: Let's here the information from Jonathan. 12:04:59 Jonathan: Gap Analysis between W3C MWBP and Korean community 12:05:22 ...I will be brief since it is not complete. 12:06:43 ...After previous TPAC, I made some modifications to this document. 12:07:22 ...I will explain the updates. 12:08:27 ...Discussion of the new gaps: COOKIE_AUTOFILL; mentioned in K-MWBP 1.5, not in W3C 12:08:54 ...NAVBAR_CONSISTENCY: mentioned in K-MWBP 1.5, not W3C 12:09:21 ...CONTENT_NAVBAR_DESIGN; mentioned in K-MWBP 1.5, not W3C 12:11:35 ...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) 12:12:15 ...IMAGES_LENGTH_UNIT (should use pixels, but no restriction) 12:12:20 Jo: Why is that? 12:12:29 Jonathan: Vendor requirement. 12:13:10 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) 12:15:05 DKA: Everything before looked OK, up to here, and this kind of contradicts what MWBP says. 12:15:18 Kai: I think they are talking about different kinds of units, not no units. 12:16:08 Jonathan: MEASURES_UNIFY, MIME_TYPE 12:16:21 Jo: So the META element is require for MIME type? 12:16:29 Jonathan: Vendor requirement. 12:16:35 Jo: 12:16:51 achuter2 has joined #bpwg 12:17:04 ... could be a difference between what HTTP and META says. 12:17:11 Jonathan: I agree. 12:18:16 Jonathan: COOKIES APPLICATION, FONTS_SUPPORT, FONT_DEFAULT, FONT_USAGE_LIMIT (all in K-MWBP 1.5, not W3C) 12:18:32 Jonathan: COOKIES_APPLICATION is in MWABP. 12:19:53 Jonathan: Details on COOKIE_AUTOFILL (Desired action: Consider for MWABP) 12:21:24 [Looking at a MWBP with the new Korean BP's added] 12:21:42 DKA: The JavaScript requirement sounds like a requirement on the device. 12:21:59 Jonathan: ECMAscript is required on the device. 12:22:33 DKA: Do you require a particular version of ECMAscript. Are you requiring CPs to use ECMASCRIPT? 12:23:01 Jonathan: If they use ECMAscript they must use 1.5. 12:24:24 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? 12:24:56 Jo: There are a number of comments and some more understanding that needs to take place. 12:26:02 Jo: 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? 12:27:04 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. 12:27:32 ...I would be surprised if this is the simplest device in Korea. What happens to people who have more basic phones? 12:28:04 ...If CP's follow these recommendations, people with basic phones won't be able to access the content. 12:29:28 Kai: 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. 12:29:37 ...I'm not sure where this leads us. 12:30:27 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. 12:30:53 achuter1 has joined #bpwg 12:31:07 Kai: The problem is mobileOK is worldwide standard, and the Korean one is different. Which one do people follow? 12:32:22 Jo: Korean mobileOK has a different goal. I don't think that it would be OK to have a UK or USA mobileOK. 12:32:42 Seungyun: Not necessary to have one DDC. 12:33:32 ...we couldn't always meet the requirements of the DDC, for example page size. It is is not necessary to have one profile. 12:34:11 PROPOSED RESOLUTION: the group accepts the idea of regional variation to the DDC. 12:34:20 ...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. 12:35:09 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? 12:35:25 Jonathan: Do they have Korean character set? 12:35:42 DKA: This is a philosophical argument. 12:36:09 Kai: My point is that there will be confusion because there are multiple mobileOK's. 12:36:32 Jonathan: Two level system: Korean and W3C mobileOK. 12:37:07 DKA: The checker will say not mobileOK for DDC, but mobileOK for Korean market, right? 12:37:45 q? 12:37:56 Kai: Isn't it about adapting pages? The server should serve up content that fits the device, even for a DDC device. 12:38:39 Jo: It is reasonable to say that CPs can develop content only for phones they want. We tell them to exploit device capabilities. 12:39:09 Kai: No we say exploit device capabilities, but need to serve something for less capable devices. 12:39:44 If a Korean page is MobileOK but is loaded into a device with no Korean chacater set, can anyone perceive it? 12:39:49 Jo: it is pointless to, for example, create iPhone apps that work on the DDC. 12:40:30 Kai: Missing the point. What Korea needs is in the W3C mobileOK. 12:41:42 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. 12:41:57 PROPOSED RESOLUTION: the group accepts the idea of regional variation to the DDC. 12:43:18 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. 12:43:42 ...then they've got the option to either do Korean mobileOK or W3C mobileOK. 12:43:50 Jo: This is a slippery subject. 12:44:10 ...the resolution as put is not correct. 12:44:25 DKA: We're not going to actually take this resolution. 12:44:40 Jo: What is our attitude to aspirational rewards? 12:45:06 ...There is one DDC; it is confusing to add a Korean DDC; should be called something else. 12:45:29 PROVOCATIONAL RESOLUTION: the group accepts the idea of regional additions to the DDC. 12:45:32 ...I support rewarding people for exploiting device capabilities. 12:46:01 ...mobileOK is about saying that content is OK for low end devices. 12:46:29 ...there should be an aspirational level. This is what the Korean work does. 12:47:37 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. 12:47:46 DKA: This is burdonsome to the Korean market. 12:47:55 Kai: Burdonsome to us too. 12:48:29 DKA: It may not make any sense for the Korean market since they have a different baseline. 12:48:59 Seungyun: mobileOK only supports the basic phone, right? 12:49:24 DKA: You can detect the phone and send content based on the capabilities of the phone. 12:49:41 ...the CP still needs to support the baseline device. 12:50:13 Seungyun: People want to see better content. People think the DDC restricts content. 12:50:35 Kai: No it doesn't. Only for a really basic phone. 12:50:46 Seungyun: But the checker will fail. 12:51:12 Kai: No the checker only checks if the content will adapt to the device. 12:52:33 Jo: You could say that if content is advertised as Korean mobileOK and not mobileOK, then that is warning. 12:52:37 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. 12:52:54 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. 12:53:16 ... DDC has nothing to do what is in the market. 12:54:21 +1 12:54:23 Kai: We have mobileOK as a baseline. If you want to go beyond that, it is OK. 12:54:42 DKA: But that isn't useful in the Korean market. 12:54:56 Kai: We have a basic misunderstanding of the DDC. 12:55:17 DKA: There is a misunderstanding in the whole world. It may be our fault. 12:56:05 Kai: Korea can be mobileOK. The only requirement is that they adapt to basic devices. Doesn't prevent them from doing great content. 12:56:52 ...the name is a problem. 12:56:57 PROPOSED RESOLUTION: ANy derivatives of the idea should avoid calling themselves mobileOK or DDC 12:58:00 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. 12:58:02 I think if we stay in restricted base line, our mobileOk cannot support advance feature in mobile web world. It's really importatant issue. 12:58:09 I suggest K-MobileOK is sufficiently different a name from MobileOK to allow for this. 12:58:18 s/importatant/important/ 12:59:07 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. 12:59:16 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. 12:59:46 DKA: You are creating a set of tests; additional checker routines, etc. 13:00:25 ...is it acceptable for you for the Korean checker to also report on the baseline mobileOK as well as the Korean mobileOK? 13:00:43 Jo: There would need to be two completely different tests. 13:01:06 Seungyun: You can already choose the type of test you want to have. 13:01:39 ...You have the option of picking either KmobileOK or regular mobileOK. 13:02:30 what about good mobile web site that made for iphone, can they get mobileOK trustmark ? currently, it's impossible. 13:02:44 DKA: No problem then. I don't think regional variations need a different name. 13:03:18 Yeliz: Are other countries required to create their own mobileOK's. 13:04:01 Kai: I think that a clearer name would be good to make it clear that this is different level. 13:04:29 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. 13:04:32 Jo: I think naming something that is an aspirational level differently than the baseline level would be good. 13:04:57 Kai: This is not an aspirational level, it is the Korean baseline level. 13:05:53 Kai: I agree, except it is not a variation of mobileOK. 13:06:02 DKA: It is a variation. 13:06:35 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. 13:06:52 Jo: We need to defer the question of naming. Since the KmobileOK contradicts some of mobileOK, it should have a different name. 13:07:11 DKA: [definition of variation] 13:08:44 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... 13:08:46 ...W3C MobileOK. 13:10:01 DKA: I'm talking about the document; a variation of that. 13:10:04 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. 13:12:07 [pause for reflection] 13:12:50 PROPOSED RESOLUTION: The working group accepts regional and other elaborations and modifications of mobileOK. Checkers which implement such altered versions of mobileOK SHOULD provide thge 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. 13:14:07 s/thge/the/ 13:14:08 Jo: This resolution doesn't require HTTP; could work on files. 13:14:25 +1 13:14:30 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. 13:14:57 Francois: What about ready.mobi; is that a form of mobileOK? 13:15:15 +1 already 13:16:08 Yeliz: Regarding the file definition; isn't that different. With files it is a partial test; isn't this different in this case? 13:16:27 -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. 13:16:40 Jo: We'd like to keep families of tests together. 13:17:19 Francois: Are stepping into copyright problems? mobileOK is copyrighted. 13:17:19 +1 13:17:36 DKA: We're talking about doing this in the working group. We need to accept it here. 13:18:15 ...we can't allow people to fork the spec since it is not in the copyright. 13:18:31 Scribe: rob 13:18:37 ScribeNick: rob 13:18:49 +1 to Jo's resolution 13:18:57 francois: we can ask Rigo on the phone this afternoon 13:19:06 DKA: we don't need that 13:19:24 jo: what wording needs to change? 13:19:46 Kai: we are not modifying mobileOK 13:19:58 We are already discussed about francois's point. 13:20:11 DKA: so just say derivations 13:20:17 Korean mobileOK policy : http://www.dt.co.kr/contents.html?article_no=2009031702010631699002 13:20:30 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 13:20:32 . 13:20:40 http://docs.google.com/Doc?docid=dhpvgnmn_61fhktmzfq&hl=ko 13:20:45 +1 13:20:48 +1 13:20:50 s/ Korean mobileOK policy : http://www.dt.co.kr/contents.html?article_no=2009031702010631699002// 13:21:07 +1 from SeanP 13:21:26 +1 13:21:41 +1 13:21:42 +1 13:21:43 +1 13:22:01 +1 provided the name of the derivation does not contain mobileOK 13:22:05 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. 13:22:06 +1 14:16:27 Jo has joined #bpwg 14:17:43 ACTION: Dan to lead discussion on list on Korean mobileOK proposals 14:17:44 Created ACTION-935 - Lead discussion on list on Korean mobileOK proposals [on Daniel Appelquist - due 2009-04-03]. 14:18:43 DKA: So i'll take the discussion forward about how we thake Korean mobileOK forward formally 14:19:16 Topic: Addendum to MWBP 14:19:17 http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20090210 14:20:15 Kai: Looking at the results of the questionnaire 14:20:35 ... there are a few typos we'll correct later 14:20:47 http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0009.html 14:22:24 achuter1: The secrion on Relevant Device Properties, are these properties that have to be detected? 14:22:53 Kai: no, we're not limiting ourselves to properties that can be detected 14:23:05 s/secrion/section/ 14:23:27 Kai has joined #bpwg 14:23:53 achuter1: there's no explanation of what the sections "Relevant Device Properties" means 14:25:14 Kai: that's what I had and it was changed because the group didn't like it 14:25:46 PROPOSED RESOLUTION: Include an explanatory section under the introduction to explain what the sections of the statements mean 14:26:03 p 14:26:36 PROPOSED RESOLUTION: for the purpose of this document relevant device properties means properties which are affected by the evaluations 14:28:05 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 14:29:32 achuter1: If it's only the properties that's ambiguous can we insert the clarification somewhere else? 14:29:52 Kai: Do we need it or not? 14:30:02 ... I think not 14:30:10 DKA: ok, it stays out 14:31:28 Kai: Jo reformulated the original texts in 1.1. Don't really want to change them back again 14:33:22 Kai: 1.2 Relationship to mobileOK Tests and the paragraph that doesn't seem to fit. What do we do about that? 14:34:09 francois: I liked the abstract's text 14:34:39 ... it's more positive text about improving UX on more capable devices 14:35:29 achuter1: Surely these evalucations are not about advanced devices, only about tests that can't be automated? 14:35:54 [Jo proposes revised text on screen] 14:35:55 jo is working on http://docs.google.com/Edit?id=dgh5r6zs_34ds9nt6kh 14:37:13 Jo: some limits need to be parameterised, as we discussed this morning with W3C DDC vs Korean DDC? 14:37:48 Kai: shouldn't we just rephrase the sentence in a more positive fashion 14:38:18 ACTION: Kai to re-write 1.2 in a more happy clappy way 14:38:18 Created ACTION-936 - Re-write 1.2 in a more happy clappy way [on Kai Scheppe - due 2009-04-03]. 14:38:33 ACTIOn: Kai to correct spelling errors 14:38:33 Created ACTION-937 - Correct spelling errors [on Kai Scheppe - due 2009-04-03]. 14:39:29 ACTION: kai to correct last paragraph of 1.2 - it doesn't have "tests" and Best PRactices should read mobileOK Basic Tests 14:39:29 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]. 14:40:02 Kai: In 2.1, my feeling is WCAG isn't referenced for good reason 14:40:12 achuter1: yes, I agree 14:41:12 ACTION: Kai to replace example in section 3.4 with an image (as it doesn't print etc.) 14:41:12 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]. 14:42:31 achuter1: In 3.4 reference for colour-blindness isn't required because there is a test for contrast 14:43:10 ACTION: Kai to provide a reference to the Ishigara Colour Blindness test 14:43:11 Created ACTION-940 - Provide a reference to the Ishigara Colour Blindness test [on Kai Scheppe - due 2009-04-03]. 14:45:06 ACTION: Kai to add a refernce to the algorithm for determining contrast 14:45:06 Created ACTION-941 - Add a refernce to the algorithm for determining contrast [on Kai Scheppe - due 2009-04-03]. 14:45:58 Kai: I know we used an algorithm to calculate contrast, I'll find that reference again 14:46:55 Kai: Thanks Alan for those comments. 14:47:14 Kai: Onto Francois's 14:47:59 francois: Section 2.1 Evaluation scope, what's this for? 14:48:31 Kai: because some tests refer to single pages, some to multiple pages 14:49:04 ... but we can drop it 14:49:56 ACTION: Kai to drop section 2. And maybe insert an explanatory section on the layout of the evaluations (to maintain numbering) 14:49:56 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]. 14:50:57 ACTION: Kai to rephrase 3.15 ref tables 14:50:57 Created ACTION-943 - Rephrase 3.15 ref tables [on Kai Scheppe - due 2009-04-03]. 14:53:05 ACTION: kai to drop 4. in 3.17 14:53:05 Created ACTION-944 - Drop 4. in 3.17 [on Kai Scheppe - due 2009-04-03]. 14:53:23 Rob: sec 3.17 the attribute wasn't standard 14:53:40 Kai: ok, we'll delete that bullet 14:54:03 ACTION: Kai to move 3.18 Note into examples 14:54:03 Created ACTION-945 - Move 3.18 Note into examples [on Kai Scheppe - due 2009-04-03]. 14:55:11 Kai: on 3.26 page title this 2nd bullet is to catch people using copy-and-paste to create pages 14:55:31 ... who forget to give pages meaningful titles 14:56:13 rigo has joined #bpwg 14:56:29 ACTION: Kai to add bandwidth to device properties in 3.30 14:56:29 Created ACTION-946 - Add bandwidth to device properties in 3.30 [on Kai Scheppe - due 2009-04-03]. 14:57:11 francois: so if you do have multiple pages of linear content we should have titles like "Results List (1/12)" 14:57:19 Kai; yes 14:57:34 s/Kai;/Kai:/ 14:59:28 francois: 3.34 table layout my main point is don't recommend a hack against a gap in the technology 15:00:01 Kai: I can rephrase this 15:00:13 Jo: I can send an example of how to do this 15:00:21 ACTION: Jo to send Kai an example of 3 col layout where column balance is maintained 15:00:21 Created ACTION-947 - Send Kai an example of 3 col layout where column balance is maintained [on Jo Rabin - due 2009-04-03]. 15:00:36 ACTION: kai to rephrase 3.34 to not call for table layout and propose CSS based solution as in DTAG 15:00:36 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]. 15:01:11 Kai: Thanks Francois for those 15:01:23 ... Onto Eduardo's comments 15:02:21 Kai: We started with this layout and the group didn't like it so we're not moving back to the old layout 15:04:15 achuter1 has joined #bpwg 15:04:45 Kai: with regard other to General remarks, these are evaluations not best practices now 15:04:58 .. and a roadmap is out-of-scope. 15:05:49 ... In detailed observations, these are npt prescriptive and are in no particular order. 15:06:17 Jo: are there dependencies between them that imply an order? 15:06:32 Kai: not particularly, no 15:07:08 yeliz: if there are dependencies, should the evaluations be combined into one? 15:07:49 Zakim has left #bpwg 15:08:02 Kai: we've completely removed any regidity in the document format. But there is a sequence, you do run these evaluations in order. 15:08:58 jo: for example 3.37 "Ensure that" is clear, "Check if" isn't. 15:09:35 Kai: This is editorial as far as I am concerned. Give me an action and I'll do it. 15:10:54 Jo: What I had hoped for was an editorial session but we've failed to find face-to-face time for that 15:11:33 ... It'd still be a good idea to have an editorial meeting, even remotely via Google Docs 15:13:15 ACTION: kai to change access to access keys in 3.1 15:13:15 Created ACTION-949 - Change access to access keys in 3.1 [on Kai Scheppe - due 2009-04-03]. 15:14:03 Kai: section 3.9 I don't see what's unfortunate about the language 15:14:53 achuter1: Fogg is just an example, there are others that are not English-only 15:15:09 Kai: This is only an example, it's clear 15:16:28 Jo: We have precident for final editorial meetings after which there's very limited change 15:16:34 [something about jerking remnants of goo] 15:16:43 DKA: when can we do this? 15:17:01 Jo: We'll set an afternoon aside 15:17:55 Kai: 3.14 bullets 3 and 4 do seem to be the same 15:18:04 ACTION: Kai to remove bullet 4 in 3.14 15:18:04 Created ACTION-950 - Remove bullet 4 in 3.14 [on Kai Scheppe - due 2009-04-03]. 15:19:27 Kai: 3.30 checks *all* CSS is used in every page 15:20:35 Rob: didn't we say this evalucation could apply to whole sites? 15:20:56 s/evalucation/evaluation/ 15:21:25 Jo: we also can't use *all* the media-selectors 15:21:43 Kai: I'll propose revised text 15:21:58 ACTION: kai to propose some text on 3.30 ref. *all* CSS for next editorial session 15:21:58 Created ACTION-951 - Propose some text on 3.30 ref. *all* CSS for next editorial session [on Kai Scheppe - due 2009-04-03]. 15:22:11 ... Thanks Eduardo for those points 15:22:40 ... Overall the changes are quite minor, so I'll issue a new draft before the editorial session 15:23:00 ... then at that point this document will be done! 15:24:46 DKA: so what date for the editorial meeting? 15:25:14 ... how about April 3? 15:26:31 Jo: 8:00-11:00 UK time? 15:27:20 Kai: ok, 09:00-12:00 CET 15:28:35 Jo: we'll edit it on Google Docs 15:28:40 zakim, room for 4? 15:28:50 Zakim has joined #bpwg 15:28:52 zakim, room for 4? 15:28:53 ok, francois; conference Team_(bpwg)15:28Z scheduled with code 26631 (CONF1) for 60 minutes until 1628Z 15:30:00 Topic: mobileOK License 15:30:06 zakim, code? 15:30:06 the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), Jo 15:30:19 Scribe: francois 15:30:36 Topic: mobileOK license 15:30:41 achuter2 has joined #bpwg 15:30:46 Team_(bpwg)15:28Z has now started 15:30:49 -> http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Trustmark/20081114.html W3C mobileOK scheme latest draft 15:30:53 +berners_lee_at_google 15:31:06 -> http://www.w3.org/Consortium/Legal/2008/04-mobileok-policy.html mobileOK license 15:31:59 achuter1 has joined #bpwg 15:32:01 -> http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0168.html Questions and responses on the mobileOK license 15:33:18 +Rigo 15:34:31 [quick round around the table to introduce participants] 15:35:03 Dan: We were just starting to review the document, and our lists of questions on mobileOK 15:35:38 --> http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0168.html REFERNCE DOC 15:36:16 Jo: Let's just step through this, shouldn't take long. 15:36:34 ... Under 1, done, wonderful. 15:36:55 ... Under 2, you're staying on "icon", right? 15:37:10 ACTION: Jo to remove the word trustmark from scheme document 15:37:10 Created ACTION-952 - Remove the word trustmark from scheme document [on Jo Rabin - due 2009-04-03]. 15:37:21 rigo: trustmark has a specific meaning, so I would strongly recommend that you do not use it in the Scheme document. 15:37:35 ... There are implications around quality. 15:37:44 ... "Icon" is more neutral. 15:37:53 jo: agreed. 15:38:33 rigo: note it's just a recommendation, I could live with "trustmark", just think it's better to have "icon" in there. 15:39:10 jo: We had a question about URIs and IRIs. Done, thank you. 15:39:22 ... Number 4: what constitutes a claim for conformance? 15:39:31 rigo: I tried a definition in 2.1. 15:39:55 ... It mainly is a phrase with certain variables. 15:40:23 ... [reading text in section 2.1 of the policy] 15:40:42 ... I should probably add 2.3 as well next to 2.2 in that text. 15:41:21 ... 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. 15:41:54 ... If you have a bunch of URIs, then you are making an assertion that each one of these URI is mobileOK. 15:42:01 s/these URI/these URIs/ 15:42:15 ... Those are the conditions to use the trademark or the icon. 15:43:12 ... 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. 15:43:23 achuter has joined #bpwg 15:43:34 jo: we need to have a technical discussion within the group as to how claim mobileOK-ness on a Web site. 15:44:10 rigo: you don't need to update the text of the policy to do that. 15:45:05 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. 15:45:21 rigo: you have to realize that you cannot test anything on non-existing stuff. 15:45:28 ... so you should include it. 15:46:25 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. 15:46:37 rigo: it's not only technical, you have to think about the marketing. 15:48:14 ... 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. 15:48:35 ... The question is: how do you identify the portion of the site that is mobileOK? 15:48:45 jo: OK, thank you. Let's move on to 5. 15:49:05 ... You just dealt with. 15:49:14 ... So, question 6. 15:49:27 ... About the use of the mobileOK string outside of a claim. 15:49:35 dan: Isn't that an example of fair use? 15:50:07 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. 15:50:16 ... You can use it, say it's crap, discuss it. 15:51:16 ... In very private stuff, it may not be so clear, but I don't think we should care. 15:51:42 jo: [going through the rest of the questions 7,8,9,10,11,12,13. All done] 15:52:13 ... Question 14 on the link associated with the logo. 15:52:49 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. 15:53:11 ... you may have a link to the mobileOK Checker, provided there's a "referer" functionality. 15:53:27 dan: Do we want to say something about that? I don't think so. 15:53:46 rido: dom and francois could talk to Olivier to have the functionality in the mobileOK Checker. 15:53:59 ... Legally, it's not a problem, we can require it, or suggest it. 15:54:11 s/rido:/rigo:/ 15:54:25 achuter1 has joined #bpwg 15:54:35 jo: On to the final point, which was actually the starting point a long time ago 15:55:00 ... The question is: using mobileOK on a page that is not itself mobileOK is just fine provided you make it clear. 15:55:08 rigo: Not even that. 15:55:45 ... You can make an assertion on TV, buses, or whatever. 15:56:08 jo: The confusion comes in when you have example.com serve different content depending on the device that requests it. 15:56:38 ... You'd like to claim mobileOK-ness even if the URI does not return mobileOK content for a given mobile device. 15:56:45 rigo: that's covered. 15:57:14 jo: I understand your point. Now that 2.2 contains "dereferenced in the manner described", it makes it a lot clearer and remove the problem. 15:57:37 s/remove the problem/removes the problem/ 15:57:56 rigo: next steps: a minor change to the license. As soon as your scheme doc is ready, we can launch! 15:58:02 PROPOSED RESOLUTION: The working group approves and endorses the MobileOK License and empowers W3C team to launch it. 15:58:19 ACTION: Jo to edit mobileOK scheme appropriately to discussion with Rigo at London F2F 15:58:19 Created ACTION-953 - Edit mobileOK scheme appropriately to discussion with Rigo at London F2F [on Jo Rabin - due 2009-04-03]. 15:58:44 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. 15:58:52 -Rigo 15:58:54 -berners_lee_at_google 15:58:55 Team_(bpwg)15:28Z has ended 15:58:56 Attendees were berners_lee_at_google, Rigo 15:58:57 [The group thanks rigo!] 16:00:25 rigo has left #bpwg 16:00:27 +1 16:00:50 +1 16:00:53 +1 16:00:54 Kai: +1 16:00:56 +1 16:01:00 +1 16:02:07 jo: I'd like to review the text before. I think the first sentence should read: "The members of W3C has developed" for instance. 16:03:24 PROPOSED RESOLUTION: The working group thanks Rigo his work on the MobileOK License which we, pending Jo's review, will launch with all speed. 16:03:39 +1 16:04:04 +1 16:04:10 ACTION: jo to review the final mobileOK license for approval during next BPWG call 16:04:10 Created ACTION-954 - Review the final mobileOK license for approval during next BPWG call [on Jo Rabin - due 2009-04-03]. 16:04:22 RESOLUTION: The working group thanks Rigo his work on the MobileOK License which we, pending Jo's review, will launch with all speed. 16:05:51 [break] 16:10:59 chair: Jo 16:11:04 acribe: Jo 16:11:13 s/acribe/scribe/ 16:11:24 scribenick: Jo 16:11:44 http://oreilly.com/catalog/9780596518738/ 16:11:58 Topic: Mobile / Accessibility Roundup 16:18:59 tigger: last item on the agenda 16:19:11 eeyore: suggest we ask for an update 16:19:16 http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/ED-mwbp-wcag-20090218/ 16:19:37 alan: The accessibility doc is nearly finished, being reviewed by EOWG 16:20:12 In principle, both WCAG and MWBP aim to improve the Web interaction 16:20:13 of users who experience barriers due to either disabilities or the 16:20:13 device used to access the Web. However, WCAG and MWBP have slightly 16:20:13 different approaches. For instance, even though WCAG in some 16:20:13 countries is a legal requirement, MWBP is not. Although some best 16:20:13 practices are testable in MWBP, testability is a key feature of the 16:20:16 WCAG 2.0 principles. However, despite these differences, they both 16:20:18 focus on user experience. 16:20:27 ... one more thing to be included ... 16:21:08 ... and once included will go to WCAG WG 16:21:31 PROPSOED RESOLUTION: BPWG agrees to inclusion of the above text from Yeliz 16:21:42 +1 16:22:21 dka: question on text 16:22:28 s/PROPSOED/PROPOSED 16:22:35 ... we don't want to rule out mobileOK ness 16:22:42 ... as a legal requirement 16:22:59 ... and it could happen there was some talk about it - yada yada 16:23:24 rob: replace no with not necessarily 16:23:43 alan: both try to improve the user experience 16:24:07 ... could be phrased in terms of usability effects 16:24:15 dka: both focus on ... 16:24:20 s/no with/not with/ 16:24:27 alan: don't require user testing 16:24:40 yeliz: improving user experience? 16:24:47 [assent to this idea] 16:25:23 dka: text goes where? 16:25:28 yeliz: overview page 16:27:11 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 16:28:21 [these differences, they both focus on user experience.] 16:28:55 alan: actually it got a lot shorter than last time it was reviewd 16:29:03 jo: shall we review it now? 16:29:06 s/reviewd/reviewed/ 16:34:30 [reviewing on screen] 16:34:40 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. 16:35:06 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. 16:35:14 +1 16:35:16 +1 to Yeliz and +1 to Alan 16:35:30 +1 to launching too 16:35:31 +1 16:35:41 +4 16:35:45 +1 16:36:32 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. 16:38:08 alan: there is another document we have forgotten about till now 16:38:29 dka: does it make sense to have another document, doesn't the shared web experiences cover it? 16:38:57 yeliz: {alarmed] what is this document, was it created before I joined the group? 16:39:01 http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/ED-mwbp-wcag-helps-20080612/ 16:39:17 s/{alarmed]// 16:41:33 [sounds of Alan typing] 16:41:55 Dna: [losing his marbles] david, shirley, what? 16:42:09 s/Dna/Dan/ 16:42:38 ... let's call it a day. If there is anything left over we can reconsdier following Alan's research. 16:43:18 ACTION: Alan to review whether there really is anything that needs bringing forward from the earlier doc 16:43:18 Created ACTION-955 - Review whether there really is anything that needs bringing forward from the earlier doc [on Alan Chuter - due 2009-04-03]. 16:43:39 Topic: Review and Meeting CLose 16:44:14 Francois: we didn't talk about mobileOK checker 16:44:47 ... I invetigated what ti would take to change mobileOK checker so it becomes more flexible 16:45:06 ... and it would be nice if we could make it flexible so you could add tests etc. 16:45:21 ... it's possible to do this and it would benefit the library as a whole 16:45:32 ... send my results to mobileOK-checker mailing list 16:45:52 ... everyone seemed fine with it and I get to implement the changes 16:46:15 ... and then we can do things like support of the file: URI extensions 16:46:24 dka: is Koprea using the same base 16:46:42 francois: yes they forked our code but it's not open source yet 16:46:58 ... they haven't released the source code 16:47:08 dka: would your changes help them? 16:47:15 francois: yes 16:47:51 dka: we should encourage them to move over to the next version 16:48:04 alan: could it be done in XML 16:48:13 francois: for now it is a kind of hybrid 16:48:21 ... not planning to do it right now 16:48:26 ... actually maybe I will 16:49:13 ... to be clear, if there are projects out there that use the library they'd have to change a bit 16:49:46 ... i.e. the changes won't be backwards compatible 16:50:03 ... there are projects other than the Korean one that use the library 16:50:12 yeliz: released as a new version? 16:50:31 francois: yes, new libaray we won't fork and won't maintain old version 16:50:36 ... that's it? 16:50:43 yeliz: what is the timeframe 16:50:52 francois: mid april I expect 16:51:11 ... but that may not be very accurate 16:51:30 yeliz: my project is coming to an end 16:51:38 francois: I will start next week 16:51:57 ... you could start work on the XSLT tests 16:52:09 ... the tests need to be redefined 16:52:22 ... canot tell etc. 16:52:33 yeliz: jo wasn't keen on cannot tell 16:52:38 s/canot tell/cannot tell/ 16:53:08 ... overall result will be CANNOTTELL if not HTTP 16:53:46 francois: the library doens't say mobileOK anyway 16:54:15 jo: mumbles 16:54:21 s/doesn't/doesn't/ 16:54:39 franocis: I'll proceed and report when it is done 16:55:01 s/franocis:/francois:/ 16:55:10 Topic: Thanks 16:55:21 RRSAgent, draft minutes 16:55:21 I have made the request to generate http://www.w3.org/2009/03/27-bpwg-minutes.html francois 16:55:35 PROPOSED RESOLUTION: Many thanks to Google and Adam for arranging it for their tremendous hospitality 16:55:41 +1 16:55:46 +1 16:55:49 +1 16:55:56 +1 16:56:01 +1 16:56:36 RESOLUTION: Many thanks to Google and Adam for arranging it for their tremendous hospitality 16:56:47 [meeting adjourned] 16:56:52 RRSAgent, draft minutes 16:56:52 I have made the request to generate http://www.w3.org/2009/03/27-bpwg-minutes.html francois 16:56:56 rob has left #bpwg 16:56:57 Zakim, bye 16:56:57 Zakim has left #bpwg 16:57:02 Jo has left #bpwg 16:57:03 RRSAgent, bye 16:57:03 I see 21 open action items saved in http://www.w3.org/2009/03/27-bpwg-actions.rdf : 16:57:03 ACTION: Dan to lead discussion on list on Korean mobileOK proposals [1] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T14-17-43 16:57:03 ACTION: Kai to re-write 1.2 in a more happy clappy way [2] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T14-38-18 16:57:03 ACTION: Kai to correct spelling errors [3] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T14-38-33 16:57:03 ACTION: kai to correct last paragraph of 1.2 - it doesn't have "tests" and Best PRactices should read mobileOK Basic Tests [4] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T14-39-29 16:57:03 ACTION: Kai to replace example in section 3.4 with an image (as it doesn't print etc.) [5] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T14-41-12 16:57:03 ACTION: Kai to provide a reference to the Ishigara Colour Blindness test [6] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T14-43-10 16:57:03 ACTION: Kai to add a refernce to the algorithm for determining contrast [7] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T14-45-06 16:57:03 ACTION: Kai to drop section 2. And maybe insert an explanatory section on the layout of the evaluations (to maintain numbering) [8] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T14-49-56 16:57:03 ACTION: Kai to rephrase 3.15 ref tables [9] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T14-50-57 16:57:03 ACTION: kai to drop 4. in 3.17 [10] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T14-53-05 16:57:03 ACTION: Kai to move 3.18 Note into examples [11] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T14-54-03 16:57:03 ACTION: Kai to add bandwidth to device properties in 3.30 [12] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T14-56-29 16:57:03 ACTION: Jo to send Kai an example of 3 col layout where column balance is maintained [13] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T15-00-21 16:57:03 ACTION: kai to rephrase 3.34 to not call for table layout and propose CSS based solution as in DTAG [14] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T15-00-36 16:57:03 ACTION: kai to change access to access keys in 3.1 [15] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T15-13-15 16:57:03 ACTION: Kai to remove bullet 4 in 3.14 [16] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T15-18-04 16:57:03 ACTION: kai to propose some text on 3.30 ref. *all* CSS for next editorial session [17] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T15-21-58 16:57:03 ACTION: Jo to remove the word trustmark from scheme document [18] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T15-37-10 16:57:03 ACTION: Jo to edit mobileOK scheme appropriately to discussion with Rigo at London F2F [19] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T15-58-19 16:57:03 ACTION: jo to review the final mobileOK license for approval during next BPWG call [20] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T16-04-10 16:57:03 ACTION: Alan to review whether there really is anything that needs bringing forward from the earlier doc [21] 16:57:03 recorded in http://www.w3.org/2009/03/27-bpwg-irc#T16-43-18