- From: Francois Daoust <fd@w3.org>
- Date: Tue, 06 Jan 2009 17:26:15 +0100
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Hi,
The minutes of today's call are available at:
http://www.w3.org/2009/01/06-bpwg-minutes.html
... and copied as text below.
Summary:
- Resolution: WAP1 content WML, WBMP and so on is to be treated
transparently (but this doesn't affect the operation of WAP Gateways and
authorised transformations as specified in xxxx [ref to be supplied by
EdC in
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0082.html])
- We had a long discussion on mandating respect of a few heuristics with
a SHOULD. No decision taken yet.
- Next calls could be merged with the remaining of the BPWG.
Francois.
06 Jan 2009
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2009Jan/0000.html
See also: [3]IRC log
[3] http://www.w3.org/2009/01/06-bpwg-irc
Attendees
Present
Francois, tomhume, Bryan_Sullivan, jo, rob, SeanP, EdC
Regrets
Chair
francois
Scribe
tom
Contents
* [4]Topics
1. [5]Mandating respect of some heuristics
2. [6]Merging task force with the working group
* [7]Summary of Action Items
_________________________________________________________
Mandating respect of some heuristics
<francois> [8]Dom's thread on mandating heuristics
[8]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0080.html
francois: This has been in the air since the CT began. Dom posted
back onto the mailing list about it. Main question is whether we
consider CT to be a generic thing, or whether it's mobile CT that
we're chartered to solve.
... I think mobile CT is the core of the guidlines. With no better
way for content providers to express their position wrt
transformation, we should provide guidelines which prevent
transformation of mobile content.
... DOCTYPE and LINK tags are amongst the only ways to determine
mobile content.
<EdC> some mime types are unambiguously mobile as well.
francois: if we view CT as a generic thing, then transformation of
mobile content could be viewed as useful. But if we view CT as a
mobile thing to render desktop sites for mobile, we should leave
mobile content well alone.
... What are the positions here?
sean: Sometimes there's content for high-end phones tagged as
"mobile" that may not work on a low-end phone. We already have a
method for keeping proxies away from content, "no-transform"
francois: requiring CPs to add no-transform is a bit worrying, in
the sense that they have to add it everywhere if they want content
to be untouched.
... I don't care if high-end mobile content is adapted for low-end
devices, because the developers will already be taking mobility into
mind
sean: the content types are XHTML, right?
francois: text/vnd.wap.wml implies mobile, but others don't
<Bryan> xhtml-mp also
sean: Images, CSS etc have to have no-transform on them anyway. The
only one you need to remove it from is the XHTML MIME type
francois: if CT doesn't alter XHTML or HTML content, it won't alter
CSS embedded in it and so on.
... it doesn't remove the need for "no-transform", just removes the
need to have it every time
<Zakim> jo, you wanted to say that just because the content is
specifically mobile doesn't mean it is suitable for the device
accessing it and to add something on cache-control:
jo: I think the idea that something is purposed for mobile, doesn't
mean that it's purposed for the device in question. We shouldn't
encourage the notion that there's just one sort of mobile content.
You should do what we say in BP2: classify devices and have 3/4
different experiences if your app warrants it. We'd be contradicting
our own best practice to say "if it's mobile leave it alone, no
matter what the device".
... I agree with Luca that asking people to have no-transform on
things that can't have META HTTP-EQUIV tags in them is unduly
onerous on developers. We should have a clause to say that if the
original page referencing resources requests no transformation, the
rule should apply to resources retrieved from this page.
<Zakim> rob, you wanted to say that these are all heuristics that
allow a CT-proxy to assume that the content is suitable as-is and it
is useful to say what these are. As Eduardo notes,
rob: I agree with Luca that it's up to operators in the proxy chain
to do no harm, but to do so they need to make some guesses, so it's
helpful to point out heuristics we use for clues. As Eduardo pointed
out, operators need control to override this with white- and
black-lists, and CPs should be aware that no-transform is another
way to get what they want if these heuristics don't deliver what
they want. All these things are useful together.
... These have to stay heuristics, partic. if you're going to allow
operators to override them (other than no-transform, which should be
strongly enforced as it gives CPs a chance to veto what happens in
front of them).
bryan: In general it's not a good idea to overtly restrict the scope
of applicability. We usefully do transformation of content towards
mobile. We also prevent things from breaking, by doing no harm -
this is a fundamental objective. So we have to operate with white
and blacklists and develop mechanisms to automate management of
these lists. We agreed as a group not to go there (rightfully so).
We need to say there are other operations necessary to modify the
beha
edC: WAP content cannot have a no-transform directive on it.
... It's been mentioned that there might be several categories of
mobile content and that CTs might modify content for different
phones. How do you know what sort of adaptation has been performed
on the CP side? I don't have much confidence that content for
high/mid/low-end phones can be distinguished.
... If you have a page marked "no-transform", then the linked
resources should be considered not transformable. This assumes
something in the implementation of CT proxies, that it preserves
state about page and can associate further HTTP requests with
earlier ones. I'm not sure this will alwys work.
<Zakim> rob, you wanted to consider making the WAP1 Content-Type
from an origin server a normative heuristic then?
rob: Is there a case for making the WAP1 Content-type a normative
heuristic rather than informational?
<Zakim> jo, you wanted to wonder if we did not already decide that
WML is considered no-transform by a resolution from last year?
jo: didn't we already say this is the case? I thought we'd taken
that resolution.
<jo> PROPOSED RESOLUTION: WML content is to be treated as though it
has no-transform attached
<francois> +1
<rob> +1
<EdC> -1
+1
<SeanP> +1
bryan: can we make a caveat to say that no-transform doesn't mean
"no compression"?
francois: the rule should only apply to the CT proxy itself... and
not to the gateways.
<jo> PROPOSED RESOLUTION: WML content is to be treated as though it
has no-transform attached (but this doesn't affect the operation of
WAP Gateways)
edC: transformation specified by WAP standards should still be
allowed.
... there are two normalised transformations. Compression of WML to
WBXML, and conversion of WML 1.3 to WML2 content.
francois: is this already defined in OMA standards?
... we should refer to that then.
<jo> PROPOSED RESOLUTION: WAP1 content WML, WBMP and so on is to be
treated as though it has no-transform attached (but this doesn't
affect the operation of WAP Gateways and authorised transformations
as specified in xxxx [ref to be supplied by EdC])
<Zakim> tomhume, you wanted to wonder about multiserved content
tomhume: are there any issues around multiserving of content where a
single page might turn out WML or XHTML, and if transformation is to
be prohibited, then a no-transform must be included for XHTML but
not for WML
<Zakim> rob, you wanted to rephrase away from "as though it has
no-transform" to "transparently" because we are not adding or
removing any Cache-Control headers
<EdC> this question is again the same issue: should we leave
mobile-specific content alone by default?
rob: shouldn't we be talking about no-transform? We're not changing
Cache-control headers. I don't think we should talk about WML being
no-transform, because it isn't necessarily. We should talk about WML
content being treated transparently and not being altered.
francois: we should say that transformations applied to WAP content
are defined elsewhere.
<Zakim> jo, you wanted to agree with tom that multiserving HTML and
WML has complications ref no-transform that we shouldprobably note
explicitly
jo: if you're delivering WML and HTML from the same URI and you want
HTML to be not transformed, you should put a no-transform on the
HTML, but not onto the WML
francois: is this a real problem? Does it create any technical
issues?
jo: it's worth noting as a peculiarity. "Don't put no-transform onto
WML, because it causes misoperation of WAP gateways".
... meanwhile back at the resolution...
<EdC> Necessary references re: WAP under
[9]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0082.h
tml
[9]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0082.html
<francois> PROPOSED RESOLUTION: WAP1 content WML, WBMP and so on is
to be treated as though it has no-transform attached (but this
doesn't affect the operation of WAP Gateways and authorised
transformations as specified in xxxx [ref to be supplied by EdC])
<EdC> What about: ... is unaltered, except as specified in XXX.
<jo> PROPOSED RESOLUTION: WAP1 content WML, WBMP and so on is to be
treated transparently (but this doesn't affect the operation of WAP
Gateways and authorised transformations as specified in xxxx [ref to
be supplied by EdC])
<francois> +1
+1
<SeanP> +1
<rob> +1
<jo> +1
<Bryan> +
<Bryan> +1
<EdC> 0 (treated transparently a bit fuzzy in my mind).
<jo> PROPOSED RESOLUTION: WAP1 content WML, WBMP and so on is to be
treated as though it has no-transform attached (but this doesn't
affect the operation of WAP Gateways and authorised transformations
as specified in xxxx [ref to be supplied by EdC in
[10]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0082.
html])
[10]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0082.html
<jo> PROPOSED RESOLUTION: WAP1 content WML, WBMP and so on is to be
treated transparently (but this doesn't affect the operation of WAP
Gateways and authorised transformations as specified in xxxx [ref to
be supplied by EdC in
[11]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0082.
html])
[11]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0082.html
<EdC> +1
RESOLUTION: WAP1 content WML, WBMP and so on is to be treated
transparently (but this doesn't affect the operation of WAP Gateways
and authorised transformations as specified in xxxx [ref to be
supplied by EdC in
[12]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0082.
html])
[12]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0082.html
francois: Back to the main part of the topic... we don't have any
new arguments here. I strongly agree with Eduardo, a developer that
started developing mobile content already has a foot in the mobile
context and can decide on transcoding issues...
... whereas a developer not aware of this has not chosen to do
anything and prob. isn't aware of transcoding issues.
... I don't think it goes against MWBP to mandate the respect of
mobile content made by mobile developers, and I don't think it
encourages mobile devs to use adaptation.
... It would send a good signal to the mobile dev community to
respect content that is already at least a bit mobile.
... we have 2 really different standpoints: one is strongly against
mandating heuristics, one in favour. I can't think of a way of
balancing the two sides. Any ideas?
<jo> PROPOSED RESOLUTION: no mandatory heuristics (sorry Dom)
<dom> booh!
<EdC> If the main idea is to allow access to desktop sites from
mobile devices, why should mobile-specific sites be caught in the
transcoding net?
sean: how about keeping this as a heuristic but mentioning it more
prominently than others?
<jo> PROPOSED RESOLUTION: Add a section saying don't just think
once, think twice about these heuristics
<EdC> Why not put the (unambiguous) heuristics under a rule SHOULD
(and not a MUST)? This means CT-proxies must have a really good
reason (and demonstrate it) to modify mobile-specific content.
francois: we could leave heuristics in two categories, but I don't
think it'll be clear for people beyond us: heuristics that carry a
semantic mobile meaning (e.g. the list Dom sent), and those that do
not.
<jo> PROPOSED RESOLUTION: Add a section saying don't just think
once, think twice about these heuristics (and then think again)
<EdC> 1
bryan: In general, it'd be good to mention the use of heuristics as
a method that should be used where possible to ensure other more
semantic methods aren't insufficient. Mandating it is difficult,
heuristics are more art than science.
... recommending it is probably valuable.
francois: EdC recommends a SHOULD not MUST. Our SHOULD is strong, so
it would be strong.
edC: I hope this could balance the two trends you mentioned earlier:
if content has been developed for mobile and these heuristics
unambiguously identify mobile content (some do not, and we must
leave them aside), then unless there is a REALLY good reason to
alter that content you should leave it alone. This is what app
providers expect.
... If you can do something reasonable with mobile content and it is
demonstrably good, then fine.
<jo> PROPOSED RESOLUTION: Specifically call out the heuristics
identified by Dom as SHOULDs and separate them from the other
heuristics that are not so strongly indicative of intentional mobile
content creation
<francois> +1
+1
<EdC> +1
<SeanP> -1
<jo> +1
<rob> +1
sean: SHOULD seems too strong. What are the requirements for it?
francois: you need a good reason to do it - i.e. you can't on a
regular basis.
... e.g. if you know the document has tables and user agent doesn't
support them: you can remove them.
sean: one reason is to put toolbars on top and bottom, even on
mobile pages. Is that reason good enough?
francois: in my view no. It's not transformation for the sake of
improving content, it's transformation for the sake of branding.
... It provides a consistent user experience.
edC: one historical example: to clean up the garbage before an XML
declaration. Many tools put comments here, screwing up mobile
parsers. Cleaning this up is a good example where mobile content
should be modifiable.
<Zakim> jo, you wanted to note that headers and footers on
no-transform content is not allowed surely
edC: adding headers usually disturbs the carefully crafted look and
feel of mobile pages, it's the most valuable real estate.
... many sites have pictures at top, navigation at footer (or head
on high-end phones).
francois: I don't see that as a valid reason not to respect the
SHOULD
... sean, are you convinced?
sean: This is what people are asking us for, so it's what we need to
do. I'd be happy with a recommendation that heuristics be followed
for mobile content, but SHOULD is too strong.
francois: MAY feels too weak, and there's nothing between that and
SHOULD
jo: a customer that says "even if the content is made for mobile,
put headers and footers on it", this doesn't follow the intentions
of the content author and respect what they might have done around
screen size and images.
... SHOULD is appropriate, on the basis that a product showing this
behaviour would not be compliant.
francois: I agree
<EdC> Let us remember that it is the deployments that are compliant
or not; the products provide the mechanisms, the policies are set by
the operators (or other customers).
<Zakim> rob, you wanted to moot that SHOULD isn't MUST and so is
appropriate but that we shouldn't go down the road of itemising all
the acceptable exceptions
rob: I'm reasonably happy with the resolution because it's SHOULD
not MUST, and SHOULD implies there will be exceptions some time. I
don't think we need to say what they are. Maybe this does involve
taking out XML comments, or adding toolbars. I don't think we're the
right place to make recommendations on what those exceptions are. I
know operators want to see toolbars on operators...
jo: so they should specify that browsers ship with them
rob: they're not getting what they want, because CPs (rightly) don't
want their content messed with. I don't think we can specify a
resolution to win that argument here and now.
jo: I think it's fine for operators to specify products to insert
toolbars, but it's not fine for us to say that's a compliant
implementation.
bryan: we have to keep clear focus on what we're developing. We're
not saying "anything you do to mobile content must comply with this
spec". If operators want ads, headers, dancing bears, that's up to
them... but outside the spec.
jo: I disagree, it's about transparency and fidelity of access path
to providers content. It's not OK for CPs to insert dancing bears
onto other peoples content. The spec intentionally (to my mind) says
this is not OK.
bryan: you're not saying "this isn't how CT must work", you're
saying "you can't have this biz model"
jo: you can have that, just not whilst complying with these
guidelines
... we're trying to provide a way to say to CPs "develop good mobile
experiences, it's the best way to get content onto mobiles". In this
doc we say "preserve fideltiy of the channel, so that mobile content
isn't messed with and their expectations can be realised".
edc: what he said... compliance with the spec is with a deployment,
not a product.
<francois> PROPOSED RESOLUTION: Specifically call out the heuristics
identified by Dom as SHOULDs and separate them from the other
heuristics that are not so strongly indicative of intentional mobile
content creation
<francois> +1
<rob> +1
<EdC> +1
<jo> +1
<SeanP> -1
+1
<Bryan> +1
<jo> [suggest we review on list and come back to this]
<jo> [one more PROPOSED RESOLUTION: Content that is an included
resource of a document treated transparently should be treated
transparently]
Merging task force with the working group
francois: we mentioned in the last BPWG call that it's a good time
to merge CT back with MWBP main body. We're not at the end but these
discussions should involve the rest of the group, who'll have to be
happy with the decision we've taken. There'll be a single call for
CT and MWBP, but when?
<francois> [13]questionnaire on next calls
[13] http://www.w3.org/2002/09/wbs/37584/BPWG-mergingcalls/
francois: depending on decision we take on thursday on this, we may
not have a CT-specific call from now.
... I'll send an update re the next call to the list. Qs?
... (there has been no decision re merging)
sean: on the timing, the current time is better than thursdays
francois: I've updated the closing date ...
Summary of Action Items
[End of minutes]
Received on Tuesday, 6 January 2009 16:26:49 UTC