Seoul BPWG F2F - report

Summary
-------
We made a lot of progress during the 2 days of the BPWG F2F in Seoul.
Thanks for those that could come to Korea!

We had a wonderful time. Many many thanks to our Korean hosts! Being 
able to get a Korean view of our Best Practices is extremely useful (the 
Mobile Wednesday workshop also helped provide an idea of the 
specificities of the Korean market, great!). We're looking forward to 
having more exchanges in the future.

Following is a "quick" and supposedly human-readable report of the work
done during the first two days of the F2F. The minutes contain more 
details about the resolutions, actions, and discussions:
http://www.w3.org/2008/03/03-bpwg-minutes
http://www.w3.org/2008/03/04-bpwg-minutes
If you've read the minutes, the following doesn't bring any new stuff.


Topics addressed
----------------
Given the time frame and the number of participants, the discussions
focused on the Content Transformation Guidelines, the Best Practices
2.0, and the mobileOK Scheme.

In particular, we did not cover other areas such as mobileOK Pro, the
relationships between MWBP and WCAG, or the mobileOK checker.

We eventually went through the list of actions and updated their status 
accordingly.


Content Transformation Guidelines
---------------------------------
The document was at the heart of the discussions for most of day 1, and
we got back to it at the end of day 2. We basically went through the
document, reviewed up to 3.1.4 (included), and resolved that apart from
the changes agreed during the F2F and editorial notes, the doc would
not change up to that point before publication as FPWD.

An editors meeting in the next two weeks was proposed by Jo to continue
the work on the document. I will organize it.

Martin suggested that the CT-Proxy should be transparent unless it can
be sure that the user agent is a browser, as it's likely that all HTTP
communications will go through the CT-Proxy. He is to propose some text
on that purpose.

On the open question of the possible alteration of a request body by a
CT-Proxy, we are looking for examples of use cases. Rob agreed to write
some pseudo-code on form transformation, and I agreed to ask Aaron for
clarification on the encoding change case. Should we clarify the page
splitting case in the doc?

On "content tasting", we resolved to drop the HEAD request as its impact
on the original server is likely to be no different than that of a GET
request (I'm to check that with a test page on different servers). We
agreed that the CT-proxy should first send a request with the original
headers, taste the response, and eventually re-issue the request with
altered headers. The tasting is not needed when the CT-proxy already has
an a priori knowledge about the resource/server. The "a priori
knowledge" is up to the CT-vendor. This raises though the question on
the assumptions that may be made about another URI from a given one. Rob
agreed to raise an issue on that question.

There remains a need to send the original user-agents along with the
modified ones. We identified 3 ways to do that that approximately match
our need not to create new technologies:
- embed the original headers in altered requests using message/http
- use an external reference to original headers using
application/external-body
- use WARNING headers in the request.
I'm to investigate the three possibilities and in particular to make
sure that the first two ones don't break existing content.

The doc will be published as first published working draft with a
dangling reference to POWDER. We may depend on POWDER provided it
progresses on the Rec track.

Soonho agreed to provide some feedback on the Content Transformation
document as SK Telecom developed an in-house content transformation
software.

We also went through Jo's "shopping list on CT" (more formally known as
ISSUE-223) and resolved a few points to make things clearer:
- We resolved that in matters of presentation, the content provider's
preference should take preference over the user's preference, but the
user should be able to exert a high-priority override over the content
provider's preference if desired. As Sean Patterson pointed out, this
goes in the same direction as CSS.
- We resolved that question of how the user signals his choices to the
CT-proxy is out of scope as a signaling question, but in scope as an
application/user interaction. We recommend that both CT Proxies and
origin servers provide user interactions to effect this.
- We resolved that in the matter of overriding "no-transform": a) it's a
user choice (which may be delegated through Terms and Conditions), and
b) with appropriate detection of non-browsers requests from the CT
Proxy, apparently malformed content will be left alone.
- We resolved that we're waiting for POWDER to express the possibility
to say "don't transform but you may tidy things up".
- We resolved that operators of CT Proxies should provide test
facilities for the benefit of content providers.

Following a discussion on the TAG finding on alternative representations
(raised as ISSUE-222), Jo is to draft a more formal comment for
communication with the TAG. Our problem is that the recommended practice
  of using distinct URI for distinct representations seems impractical.
 From a Content Transformation point of view, there doesn't seem to be a
way to distinguish between a URI that points to a specific
representation of a resource (and may not require any content
transformation) or to a resource with multiple representations. Besides,
the recommended use of the <link> element only applies to HTML,  and we
would like to be able to apply it to a broader range of content
(typically images). Should we emphasize the need for the return of the
Link HTTP header?


Best Practices 2.0
------------------
Bryan basically edited the document live...
The latest draft reflects the discussions and decisions taken during the 
F2F:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20080305

The scope of BP2 was much discussed. Based on the comments made on the
mailing-list and starting from Jeff's list, we agreed to define web
applications as applications that typically have many of a list of
characteristics. See the latest draft, section 1.4.

The criteria for Best Practices recommendations was discussed. See the 
latest draft, section 1.4.1.

The non-HTTP schemes were discussed. Dan would like the BP document to 
include easy-to-understand terminology and is to raise an issue on the 
terms used (main page, external resources, ...)

The HTTP compression was discussed. Dan wanted to reference EXI but
there's no implementation of EXI so far, so we may only reference it as 
an example and recomment more generic and standard mechanisms such as 
gzip. Charles is to check the status of compression in the 
XmlHttpRequest API.

The idea to be able to detect the user's type of access and the amount
of data he's willing to receive was mentioned. There could be a BP on
letting the user provide this kind of information [named 
DISCLOSE_AUTOMATION in latest draft].

"Push" was discussed and Jo will raise an issue on the availability of 
binding to an incoming SMS from script.

Size was discussed. We agreed to have 3 "minimize" BPs: minimize 
application size, minimize DOM manipulation and minimize external script 
files.

Sunghan presented its contribution on the emphasis to give on a seamless 
user experience whatever the device. Charles noted that current scope 
doesn't say that best practices also work on the Web, only on the mobile 
web. We need some more input to address the problem in terms of best 
practices. Sunghan agreed to provide some more actionable statements on 
this.

The iPhone developer's guide was reviewed but at first glance doesn't 
contain clear BP we may re-use. Dan is to summarize and extract BPs from 
the guide, and from the Frost library as well. I'm to do the same thing 
with the University of Helsinky masters thesis.

Jonathan explained the adjustements made to the best practices to fit 
the Korean market, and presented a proposal for an Advanced Delivery 
Context (ADC) we might use for BP2. Jo noted that DDC is the "minimum" 
delivery context for reasonable experience of the Web and that BP2 is 
about using features when they are available. This explains why we did 
not define an ADC for BP2. But we may need to revise our definition of 
the DDC for BP2 and include accordingly revised BPs from BP1. Jo is to 
raise an issue on that. We agreed to include a BP that recommends the 
classification of devices into High, Mid, Low.

Jonathan is to extract BP statements from the Korean version of BP2 
(actually named K-MWBP 1.5).


mobileOK Scheme
---------------
The mobileOK Scheme eventually has an editor! Charles agreed to take on
the task and produce a draft by next Thursday.

The doc needs to address how mobileOK relates to the Best Practices, if
it's a trustmark, put in legal terms that the mobileOK Checker is not
normative but a reference implementation, and so on. There are still
some legal issues regarding the use of "mobileOK". Dom reported in an
email shortly after the meetings that licenses should be available by
the end of the month.

Dan proposed to write a usage scenario for mobileOK Scheme.

It was resolved that there would be an aspirational level of mobileOK
represented by a "badge" to say "mobileOK checked". The goal is to be
able to say: "I intended to be mobile-friendly".



François.

Received on Sunday, 9 March 2008 13:03:41 UTC