See also: IRC log
francois: following discussion
on-list, Eduardo proposed an algorithm to define "improving the
user experience", which is tough to define
... to me this is out of scope as we've decided not to describe
the internal operations of proxies
eduardo: agree to leave the algorithm out of scope
<francois> ISSUE-284?
<trackbot> ISSUE-284 -- W3C mobile addressing standards -- RAISED
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/284
francois: jo raised this issue
after the Verizon statement, where they claimed to follow the
CT guidelines but advised URI patterns which CT lists as
examples
... the interpretation was also that desktop user-agents should
be substituted by default. This is contrary to the guidelines
we're writing.
<francois> PROPOSED RESOLUTION: Add some text in 4.1.5 to state that inferring that a desktop User-Agent is needed in the absence of any indication (e.g. URI patterns) is contrary to the guidelines
SeanP: Verizon are working on changing this document.
jo: we're starting to put things in because we've seen them in the wild, which is risky
<francois> +1
<jo> +1
+1
<EdC> +1
RESOLUTION: Add some text in 4.1.5 to state that inferring that a desktop User-Agent is needed in the absence of any indication (e.g. URI patterns) is contrary to the guidelines
jo: would like a resolution on the subject of reinforcing the text in the Heuristics appendix to say "these are just heuristics"
francois: feels the guidelines are clear, but could be emphasised some more
<jo> PROPOSED RESOLUTION: Beef up text on Heuristics to say that they are *not* endorsed and are not even recommended as good practice
<andrews> +1
+1
<francois> +1
Eduardo: wonders why they're not recommended as best practice
jo: if we say "it's good practice
to use these" we're endorsing them.
... we're saying "this is not advice of best practice, just an
observation of what people do"
... Verizon said "these are the W3C endorsed mobile addressing
patterns", but we don't endorse them.
... I wouldn't want us to say "it's good practice to use
x.domainname or domainname/x", but it's worth our saying "if
you're building a CT proxy, these are the things people
typically look out for"
... it's unsound to recommend people parse site entry points in
any way, it's worth noting that people do do that.
... you should send unaltered headers in the first
instance
... the pattern of the name should inform you re your decision
to do this
Eduardo: wasn't the Verizon thing taking the counterposition of the guidelines?
SeanP: I'd like to amend the proposed resolution to say they're not endorsed, but also say "you can't deduce that a site isn't mobile by looking at these patterns"
Bryan: you can't reliably
deduce... but the issue of using specific url/domain-naming
conventions is that it's a practice that isn't considered "best
practice" but has support.
... unless it's driven by W3C/IETF recommendation, we're in
danger of creating technology. e.g. some older browsers used
WSP instead of HTTP, and it was dropped after a lot of
pain
... we should avoid similar situations by implying that this is
a proposed technology approach
Eduardo: saying that some of these practices aren't good practices will have to be checked. e.g. .mobi domain *is* good practice to recognise a mobile site
francois: jo, could you suggest some text on the mailing list?
<jo> ACTION: Jo to propose beefed up text on heuristics in respect of practice vs good practice [recorded in http://www.w3.org/2008/11/25-bpwg-minutes.html#action01]
<trackbot> Created ACTION-886 - Propose beefed up text on heuristics in respect of practice vs good practice [on Jo Rabin - due 2008-12-02].
francois: we mentioned POWDER as a possibility to let servers communicate with CT proxies. From the clients POV we don't have such a reference, CC/PP could be used a bit more in future. We could refer to this in "scope for future work".
jo: CC/PP should be retired in a dignified fashion
bryan: we should look forward to
new technology to solve this problem. The OMA Mobile Client
Environment MCE group is defining an ontology for device
capabilities. Should see something coming to the market in the
next year or two.
... (that's the OMA mobile client environment MCE group)
<francois> PROPOSED RESOLUTION: do not reference CC/PP in Scope for Future Work as a possible future way to communicate between a mobile device and a CT-proxy because it probably won't be used as such.
<jo> +1
<EdC> +1
<francois> +1
<SeanP> +1
RESOLUTION: do not reference CC/PP in Scope for Future Work as a possible future way to communicate between a mobile device and a CT-proxy because it probably won't be used as such.
francois: conclusion of the
discussion from the mailing list was that all normative
statements must be testable. We must avoid wishful thinking or
unclear statements.
... two statements in particular aren't testable, both in
4.2.8.1
<francois> section 4.2.8.1
francois: we have 2 statements saying a proxy must do its best not to break content, and only adapt to make things better for user agents
francois: how can we reword this along the lines of the Best Practice we have on exploiting device capabilities, or do we need something else?
Eduardo: The first paragraph in
4.2.8.1 is questionable on 2 grounds: it's not testable, and it
introduces a restriction in setting the scope for what kind of
transformations are allowed
... there are transformations to match the capabilities of the
network, not just the handset (e.g. to encode/decode content).
This statement prohibits that kind of application.
francois: doesn't think we want to be this rigid
Eduardo: there is a document about MWBP, if there should be something stated it should be to that document (perhaps w/chapter references), not as a normative statement but as an indication
bryan: this is similar to earlier
statements we had re the scope of the document. When this doc
restricts what a CT proxy can do, it should be explicit that
this is only within the scope of what a CT proxy is intended
for (translating for purposes of usability), and not for e.g.
reducing load of network, which should be outside the scope of
these guidelines.
... these statements are OK but shouldn't imply a restriction
on the same system that's doing CT for other purposes.
<Zakim> jo, you wanted to agree with the point that these are poor as they stand, and to suggest that someone drafts some proposed text for these bits
jo: happy to adopt that text, but think reformatting images *is* within scope for this doc.
SeanP: agree this should be non-normative, but not sure referring to BP is much better. "Exploit device capabilities" isn't any more testable than what we have here.
jo: how about striking these
sections altogether?
... this is leaning towards talking about proxy internals.
proxy vendors should be free to make a lousy product.
eduardo: introduction of guidelines talk about improving user experience. There could be an indication in an appendix to BP as an information reference.
<francois> PROPOSED RESOLUTION: Strike first paragraph in section 4.2.8.1 on transformations carried out by CT proxies as it refers to what CT-proxies do (stated in the introduction) and does not have any normative meaning.
<Bryan> +1
jo: we've had comment that the bits that matter here (points 1/2/3) get lost in the body
<francois> +1
<SeanP> +1
+1
<jo> +1
RESOLUTION: Strike first paragraph in section 4.2.8.1 on transformations carried out by CT proxies as it refers to what CT-proxies do (stated in the introduction) and does not have any normative meaning.
<EdC> +1
<andrews> +1
francois: appendix already contains reference to BP
<jo> ACTION: Jo to put a reference somewhere to the Best Practice about exploiting device capabilities [recorded in http://www.w3.org/2008/11/25-bpwg-minutes.html#action02]
<trackbot> Created ACTION-887 - Put a reference somewhere to the Best Practice about exploiting device capabilities [on Jo Rabin - due 2008-12-02].
<jo> ACTION: Jo to be lucky :-) [recorded in http://www.w3.org/2008/11/25-bpwg-minutes.html#action03]
<trackbot> Created ACTION-888 - Be lucky :-) [on Jo Rabin - due 2008-12-02].
francois: eduardo, you'd like it
to apply to 4.2.8 in the list of heuristics
... one of the heuristics would be that the proxy would examine
the user-agent
... this goes with features like zoom capability
<francois> "the user agent has linearization or zoom capabilities or other features which allow it to present the content unaltered"
eduardo: it's actually not general enough. you might have desktop-capable user agents on a mobile device without linearization, but that's still able to access content from a web server. So you can keep that bullet-point, but there are other properties of user agents which you have to take into account to deal properly with the decision to transform.
jo: what do we need over and above the phrase "other features"?
<jo> PROPOSED RESOLUTION: Reword "the user agent has linearization or zoom capabilities or other features which allow it to present the content unaltered" "the user agent has features such as linearization or zoom that allow it to present the content unaltered"
<jo> PROPOSED RESOLUTION: Reword "the user agent has linearization or zoom capabilities or other features which allow it to present the content unaltered" as "the user agent has features (such as linearization or zoom) that allow it to present the content unaltered"
francois: perhaps "the user agent as identified by some evidence in the http request"?
eduardo: didn't someone say evidence is a terminology in some other group?
francois: used by the DDR Simple API
jo: we don't care how the user agent is determined
RESOLUTION: Reword "the user agent has linearization or zoom capabilities or other features which allow it to present the content unaltered" as "the user agent has features (such as linearization or zoom) that allow it to present the content unaltered"
<francois> Close ACTION-880
<trackbot> ACTION-880 Review LC-2053 and clarify to group closed
francois: in 4.2.8.1 Jo inserted a note instead of what had been agreed. Are we fine with the note?
jo: the note should be moved to the top of the section
<jo> PROPOSED RESOLUTION: Move the note under 4.2.8.1 to the start of the section
<francois> +1
RESOLUTION: Move the note under 4.2.8.1 to the start of the section
<francois> ACTION-881?
<trackbot> ACTION-881 -- Jo Rabin to enact resolution on 4.2.8.1 ref adding character-encoding to the list of format, layout, dimensions etc. -- due 2008-11-17 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/881
<francois> Close ACTION-881
<trackbot> ACTION-881 Enact resolution on 4.2.8.1 ref adding character-encoding to the list of format, layout, dimensions etc. closed
francois: for the time being, it says SHOULD validate. Discussion on the mailing list is that we could split this into 2 guidelines: content MUST be well formed (if it's XML), the second being that it SHOULD validate to a formal grammar.
<EdC> are there other formal notions of well-formedness than just for XML?
<francois> PROPOSED RESOLUTION: ref. Validation against formal published grammar, two guidelines "The altered content MUST be well-formed (if it's XML-based)" and "The altered content SHOULD validate to an appropriate published formal grammar"
francois: if we split into 2 guidelines, will it be misunderstood?
<Zakim> jo, you wanted to say that it is probably clearer as it is
jo: it already echoes the
language of the BP doc, I'd rather leave as is
... the doc says it SHOULD validate according to a published
formal grammar. If there's no published formal grammar for the
content type, this can't be complied with (hence this being a
SHOULD) and there are reasons not to comply with formal
grammars even when you can (hence SHOULD)
... ponders what virtue there is to well-formedness
eduardo: if we ask for well-formedness we're stating a minimum
jo: it should still only be a SHOULD; there are cases where well-formedness works less well than non-well-formed on some devices
eduardo: is there an example
where non-well-formedness is an example? we couldn't see
one.
... there are examples where you want to restrict the whole set
of well-formed documents to a smaller set, because of browsers
being particular. But these are still well-formed
documents.
SeanP: if we put in a statement about well-formedness, what does it buy us here? Proxies aren't going to create non-well-formed if browsers can't handle them ("don't put in bugs") so why do we need this?
eduardo: if best practice is not to put in bugs, well-formedness is the way not to put in bugs.
francois: I share Sean and Jo's POV, that there isn't enough added value to say "content must be well formed" given that there could be an example where this isn't required. What value does having two statements instead of one add?
<jo> -1 to well formed
<EdC> +1 to wf
<francois> 0 to well formed
<Bryan> -1
0
<andrews> 0
<SeanP> -1 to well formed, but I don't care that much
francois: let's think about this and return to it next week