Mobile Web Best Practices Working Group Teleconference -- 06 Jan 2009

Mandating respect of some heuristics

<francois> Dom's thread on mandating heuristics

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

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

<SeanP> +1

<rob> +1

<jo> +1

<Bryan> +

<Bryan> +1

<EdC> 0 (treated transparently a bit fuzzy in my mind).

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

<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

<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> questionnaire on next calls

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

Mobile Web Best Practices Working Group Teleconference

06 Jan 2009

Attendees

Contents

Mandating respect of some heuristics

Merging task force with the working group

Summary of Action Items