- From: Francois Daoust <fd@w3.org>
- Date: Tue, 25 Nov 2008 18:07:09 +0100
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Hi,
The minutes of today's call are available at:
http://www.w3.org/2008/11/25-bpwg-minutes.html
... and copied as text below.
Resolutions taken during the call:
- 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
- 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.
- 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.
- 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"
- Move the note under 4.2.8.1 to the start of the section
Francois.
-----
25 Nov 2008
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0077.html
See also: [3]IRC log
[3] http://www.w3.org/2008/11/25-bpwg-irc
Attendees
Present
tomhume, Bryan_Sullivan, Eduardo, francois, SeanP, Andrew, jo
Regrets
rob
Chair
francois
Scribe
Tom
Contents
* [4]Topics
1. [5]User experience
2. [6]W3C mobile addressing standards
3. [7]Capability negotiation on the client side
4. [8]"Dry" statements for Alteration of Response and LC-2053
on Classes of Devices (4.2.8.1)
5. [9]LC-2023 - note instead of alteration of the list
(4.2.8.1)
6. [10]Validation against formal published grammar (4.2.8.1)
* [11]Summary of Action Items
_________________________________________________________
User experience
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
W3C mobile addressing standards
<francois> ISSUE-284?
<trackbot> ISSUE-284 -- W3C mobile addressing standards -- RAISED
<trackbot>
[12]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/284
[12] 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
[13]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].
Capability negotiation on the client side
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.
"Dry" statements for Alteration of Response and LC-2053 on Classes of
Devices (4.2.8.1)
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> [14]section 4.2.8.1
[14]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/081107#sec-alteration-of-response
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
[15]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
[16]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
LC-2023 - note instead of alteration of the list (4.2.8.1)
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>
[17]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/881
[17] 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
Validation against formal published grammar (4.2.8.1)
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
Summary of Action Items
[NEW] ACTION: Jo to be lucky :-) [recorded in
[18]http://www.w3.org/2008/11/25-bpwg-minutes.html#action03]
[NEW] ACTION: Jo to propose beefed up text on heuristics in respect
of practice vs good practice [recorded in
[19]http://www.w3.org/2008/11/25-bpwg-minutes.html#action01]
[NEW] ACTION: Jo to put a reference somewhere to the Best Practice
about exploiting device capabilities [recorded in
[20]http://www.w3.org/2008/11/25-bpwg-minutes.html#action02]
[End of minutes]
Received on Tuesday, 25 November 2008 17:07:46 UTC