See also: IRC log
The day started with a discussion on SVG and Canvas for the Mobile Web Application Best Practices (MWABP) specification. The rest of the day was spent addressing the remaining issues on the Guidelines for Web Content Transformation Proxies (CT) specification.
<jeffs> http://www.it.rit.edu/~jxs/test/canvas/action910draft.html
jeffs: it's a draft for
content
... about when to use SVG or canvas and added a ref that you
should use rich interfaces
... actually that there are variety of such interfaces
available
... you don't need to draw buttons if all you need are
buttons
DKA: conversation yesterday was
whether it is really a best practice, enough usage, enough
reference material to recommend the use
... is it a forward looking BP rather than something based on
existing practice
jeffs: I wanted to include this
because more and more full featured browsers in the mobile
domain canvas is becoming much more tempting
... it is forward looking in that it is available, but not that
much forward looking
Jo: is there anything in canvas you cannot do with svg?
jeffs: they are similar. the
primary diff is that svg will give you a heavier dom and uses a
compound doc like approach by the browser vendors
... canvas is easier. It is a blank slate you just draw on. It
is lighter weight, for a developer and you don't have to learn
a new language
EdC: Is there are rec when to use svg or canvas?
DKA: we don't really want to get into the debate but want to talk about using device capabilities
adam: can you use canvas from the dom?
Jo: Yes
jeffs: no you cannot. You can change the height, but the content is not visible in the dom
Jo: the problem with Javascipt is that browser consumes the content. What is important is that content is available.
jeffs: that's when you want to use svg.
Jo: so we should ban JS :-) other than for cool interaction effects
Jo: now we are getting into personal opinion, not best practice
jeffs: I think that is not true. I have pointed out concrete situations where it makes more sense to use svg or canvas and have tried to stay out of the debate
EdC: But you have stayed at low
level arguments in you text. I like what Jo said about content
being discoverable
... so we should recommend svg and discourage canvas
jeffs: if you want it to be discoveralbe then you need to use svg, but don't want to discourage canvas because it is so light weight
SeanP: are there other categories where this fits into, as discussed yesterday? like conservative use of resources?
jeffs: i missed that
conversation. I guess it would fit into conservative use of
resources. It is less intensive than doing dom
manipulation
... canvas will be valuable for information display
... hard to teach in svg, but easy to do in canvas
... one could talk about it in terms of information display
rather than dynamic graphics
... it makes sense to say that browsers are supporting this tag
and we should tell people when to use it
DKA: should we recast this as a
cautionary notes on the use of dynamic graphic elements
... can discuss the pros and cons of svg and canvas
jeffs: I would not object to
that
... I would rather put this in positive terms, but we can do
that
DKA: doesn't have to be
negative
... I have a problem saying use canvas
adam: should be use the appropriate rendering api
DKA: yes, that way we could tell people what exists
jeffs: should we say use the appropriate rendering api or dynamic graphics
Jo: we should say don't use canvas unless you can"t think of another way
jeffs: canvas is about dynamic
graphics.
... don't use it to draw user controls
Jo: I think it would be good to
say not to draw buttons
... lot"s to say how not to use it
<francois> Definition of the canvas element in HTML5
DKA: Isn't there something about drawn graphics which are useful if you don't know screen size
jeffs: if you feel you must draw buttons
DKA: perhaps we should encourage people to draw buttons because of scalability
SeanP: hopefully the device will know how to draw buttons
jeffs: we need to help people in
situations were all three possibilities can be used
... I agree with Sean
francois: I posted an extract
from HTML5 about canvas
... [reading]...
... they are still discussiing. It is a draft
... for the time being it is not clear
... there is not much to discuss at the moment
... it is an api and could have it on top of svg perhaps
... you can mix and match and play with the output
... in the past with svg we had no bp to promote
jeffs: that is an important
point
... there is a temptation here if the developer doesn"t care if
the content of canvas is not available
... svg is another hurdle and feels heavier
DKA: is there are mobile specific angle that the html5 guys may not have thought of
francois: it is about scalable vectors, scaling graphics, everything will adjust
DKA: and it is lower size
SeanP: we discussed the difference between various technologies in graphics. Can we say use this rather than that?
Jo: what is mobile here?
DKA: screen sizes, dynamically
adjusting buttons
... in order to render that independent of screen size
... without having to make several images
... what can we say that is relevant to the mobile space?
jeffs: sucking resources dry is
mobile
... I think that dynamic graphics using svg will be much
heavier and coder brain power, rather than using the drawing
api of canvas
Jo: you seem to be saying that developer efficiency is important compared to run time efficiency
jeffs: Yes
... if it is dynamic then use it, not for static stuff
DKA: I suggest jeffs comes up with a new articulation of the deep analysis we just had
jeffs: I can do that. What is the focus?
Jo: mobile specific aspects
DKA: dealing with screen sizes and resolutions, efficency across the wire, but also rendering resources
adam: I feel uncomfortable about
making non backed up statements about resource
consumption
... where are the threshholds?
DKA: should we ask Dom to come up with something?
adam: that would be useful
<francois> http://www.borismus.com/canvas-vs-svg-performance/
<Zakim> Bryan, you wanted to ask what is the specific reason that SVG vs canvas is heavier in processing requirements - reliance on DOM in somw way?
Bryan: could we document what the
reasons are why canvas is lighter weight?
... isn't that similar to what we talked about yesterday
regarding relying on the dom?
jeffs: i thought the group had concluded that dom manipulation is resource heavy
Bryan: that seems to be challanged by adam
adam: we need values for this
jeffs: francois article may be useful. There are some metrics
adam: the document is not for mobile devices
francois: it is an
indication
... it is dependent on the size of what you draw
jeffs: graphics that are redrawn
a lot are better done in canvas
... I will see if I can get people to try some stuff out on
various maschines
DKA: perhaps Dom could be helpful with this
francois: I fear we will end up with figures and no immediate conclusion
Jo: I think it is to early for a BP
DKA: I think we cannot say that now
Jo: an analysis will help in showing that it is too early
DKA: what could we say about exploiting device capabilities?
<Jo> PROPOSED RESOLUTION: It's too early and too speculative for a BP on SVG Canvas etc.
<francois> +1
<DKA> -1
<jeffs> -1
jeffs: I don't agree
+0
<EdC> +1 too early as a best practice (should be based on substantiated experience).
Jo: I don't know if you will find anything that will change the fundamental problem
DKA: we need to see if there is a lot of use
<Jo> PROPOSED RESOLUTION: It's too early and too speculative for a BP on SVG Canvas etc. plus there is not a specific enough mobile motivation for any such statement
DKA: nobody has said what people
are really doing with it
... if there are many then I don't agree
<DKA> -1
jeffs: I'd rather not spend
energy on something that will not be useful
... in teaching i found that svg has a feeling of being heavy
and canvas is not
<rob> +1 unless there is specific mobile advice to give about vector graphics in general
jeffs: as for what is in use that is speculation
DKA: we need more info
... existing web apps that use svg or canvas
... who would want to find out which web apps, like apple's,
are using svg or canvas?
Jo: I think we are wasting time
DKA: what if there are
many?
... otherwise we are doing a good service to the readers
jeffs: I think we should show people how to use this
Jo: this has not been established as a BP
DKA: I propose Jeff and I work on
it
... let's close off discussion on this
<Jo> ACTION: Dan and Jeffs to wander the highways and byways of SVG and Canvas and cook something up for the group's approval [recorded in http://www.w3.org/2009/03/26-bpwg-minutes.html#action01]
<trackbot> Created ACTION-924 - And Jeffs to wander the highways and byways of SVG and Canvas and cook something up for the group's approval [on Daniel Appelquist - due 2009-04-02].
<DKA> 15 minute break
<DKA> http://en.wikipedia.org/wiki/WIPI
Dan: Let's pick a contentious
issue to start with.
... We need to get to all this stuff today.
Jo: Let's go with ACTION-902
DKA: Where do we stand on this?
Jo: There were 3 fundamental
questions.
... 1. Link rewriting is a form of CT and subject to the same
restrictions as other transformations
Francois: The security problems are caused by the changing of the origin of the link, no necessarily the link rewriting itself. Adding links can also be a problem.
DKA: I'm not sure how this helps us with the discussion.
Francois: We need to be clear in the document that insertion of links also is like link rewriting.
DKA: How about making our definition of link rewriting to include insertion of links.
<Jo> PROPOSED RESOLUTION: IN the following and in all subsequent discussions Link Rewrioting is considered to include insertion of links that introduce the "ame domain" issue
DKA: For positions where we have two different opposite viewpoints, maybe each person should take the other's sides.
<Jo> PROPOSED RESOLUTION: In the following and in all subsequent discussions Link Rewriting is considered to include insertion of links and frame flattening and other techniques that introduce the "same domain" issue
<Jo> > PROPOSED RESOLUTION: In the following and in all subsequent discussions Link Rewriting is considered to include insertion of links and frame flattening and other techniques that introduce the "same origin" issue
Rob: What about flattening out the frameset, where you end up with several documents all placed into one document after CT?
<rob> +1
<francois> +1
+1
<Jo> +1
<Kai> +1
<DKA> +1
<Bryan> +1
<JonathanJ> +1
RESOLUTION: In the following and in all subsequent discussions Link Rewriting is considered to include insertion of links and frame flattening and other techniques that introduce the "same origin" issue
<Jo> PROPOSED RESOLUTION: Link rewriting is a form of transformation and at a minimum is subject to the same limitations as other forms of transformation described in this document
<rob> +1
<francois> +1
+1
<EdC> +1
<DKA> +1
RESOLUTION: Link rewriting is a form of transformation and at a minimum is subject to the same limitations as other forms of transformation described in this document
<JonathanJ> +EOF
Bryan: It might we worthwhile to note that it is an aspect of non-proxy operation. Link rewriting is unnecessary if the CT proxy is acting as a true proxy.
Rob: You may need to rewrite URIs with frameset flattening, pagination, and javascript links.
Bryan: True, but it is important to note that in proxy mode link rewriting is not always necessary, but for a non-proxy mode CT proxy it is always necessary.
DKA: Can you make a resolution on this?
<Jo> PROPOSED RESOLUTION: Proxies MAY rewrite links, where content transformation is permitted, providing that content domain origin distinctions are preserved by the proxy.
Rob: Is the Google transformation engine out of scope.
DKA: Can you explain this Jo?
Francois: I though we agreed that this wouldn't work.
Jo: There are two parallel threads here. 1. Is this required for hygene on the web? 2. Are the techniques available?
Francois: Should we do the techniques first?
Rob: There are two parallel threads and the answer to both is yes.
<DKA> +1
Jo: What we mean by this resolution is that content domain origin distinctions are preserved.
Rob: Do we mean that content domain origin distinctions are kept between the CP and the CT proxy or the CT proxy and the handset?
<Bryan> +1
Rob: We are trying to preserve security; safety from cross-domain attacks.
<Zakim> Bryan, you wanted to explain that we should give an example of how "domain origins distinctions can be preserved"
<Jo> PROPOSED RESOLUTION: Proxies MAY rewrite links, where content transformation is permitted, providing that content domain origin distinctions are preserved by the proxy such that browsers accessing the proxy do not inappropriately misconstrue different content origins as being the same and inappropriately share cookies, or allow execution of scripts or do other things that cause security...
<Jo> ...problems as a result of not knowing that different origins are involved
Bryan: We should provide an example of how domain origins can be preserved. To me this isn't clear and needs to be shown.
Jo: I agree. We need to show that there are techniques that it can be done and that it is testable.
<francois> +1
<Kai> +1
<DKA> +1
+1
<rob> +1
<Jo> +1
<Bryan> +1
<JonathanJ> +1
<Jo> PROPOSED RESOLUTION: Proxies MAY rewrite links, where content transformation is permitted, providing that content domain origin distinctions are preserved by the proxy such that browsers accessing content via the proxy do not inappropriately misconstrue different content origins as being the same and inappropriately share cookies, or allow execution of scripts or do other things that cause...
<Jo> ...security problems as a result of not knowing that different origins are involved
<Jo> +1
<EdC> +1
<JonathanJ> +1
<francois> +1
<DKA> +1
<rob> +1
<Jo> +1
+1
RESOLUTION: Proxies MAY rewrite links, where content transformation is permitted, providing that content domain origin distinctions are preserved by the proxy such that browsers accessing content via the proxy do not inappropriately misconstrue different content origins as being the same and inappropriately share cookies, or allow execution of scripts or do other things that cause security problems as a result of not knowing that different origins are involved
Jo: We need to show that there are testable techniques.
Francois: I don't really understand the testable parts. Do we need to show the testable techniques in the guidelines.
Jo: Since you own the conformance statement, you need to do it.
Rob: The problems are in the DOM; needs to be testable in the DOM spec.
Francois: There needs to be something testable in the proxy.
Rob: Testable the same way as in a browser.
Francois: What are the examples?
<Bryan> Here is the proposed informative text "Link rewriting is always used by CT Proxies that are accessed as an origin server initially, e.g. which provide mobile-adapted web search and navigation to the web pages returned in the search results, or to which the browser is redirected through the CT Proxy for adaptation of a web page. Link rewriting *may* be used by CT Proxies acting as normal HTTP proxies (e.g. configured or transparent) for the browser, but may not b
<Bryan> e required since all browser requests flow through the CT Proxy."
Rob: Look up XXS.
<francois> Cross-origin resource sharing draft
Francois: There is some work to
allow cross-origin resource sharing.
... based on HTTP header fields saying I allow access to the
other origin.
Jo: Isn't that easy to subvert.
Francois: May be more involved than that.
DKA: Let's not get into philosophical discussions.
Francois: We need to provide some examples of how same origin can be preserved.
Rob: One reason for rewriting URIs is that they get too long. Many handsets truncate URIs at 256 characters.
Jo: Let's summarize the
techniques that we have discussed today.
... differences in ports does not work.
Rob: Not all ports are are open as well.
Jo: Can't use subdomains.
Francois: Having a star in the DNS record doesn't work as Bryan pointed out.
Jo: Can't use URI decorating.
Rob: So come back to how most CT proxies work, and that is use a single domain for which the rest of the web is available.
Eduardo: If scripts are passed down to the handset then you could have a problem.
Rob: But the scripts are executed on the CT proxy. This is where the guidelines come into play, which says that CT proxy needs to execute scripts and handle the cookies.
Eduardo: How can we say that in the guidelines?
Rob: We need to do some tests like with browsers, but on the proxy.
Eduardo: Where do you do the tests?
Rob: You do the tests on the origin server.
Kai: Why are we worried about this. If some one wants to do this they won't care about this document.
Rob: The tools are there already.
<francois> DOM conformance test suite
Francois: We can use the DOM conformance test suite.
Jo: Which is the relevant specification for the tests?
<DKA> +alan
Bryan: I wanted to comment on something said by Rob about the CT proxy handling the cookies and scripts; I think this is true in non-proxy mode. However, we don't do this in proxy mode. We wouldn't want imply that a CT proxy always has to manage cookies.
Rob: True, but if it is necessary to execute the scripts on the CT proxy, then for consistency the CT proxy needs to handle the cookies.
Bryan: OK, but we want to be clear that just because the CT proxy handles cookies for some pages on the domain, it doesn't have to do it for all pages on the domain.l
Rob: Yes, we just need to say that if a CT proxy handles the scripts, then it needs to handle the cookies.
s/domain.1/domain/
Francois: these tests don't cover the cookies.
Rob: Yes, but there are tests that cover cookies.
DKA: Can we reference these tests right now and look at them later?
Jo: We need to look at them
first.
... Let's take a resolution that since we don't think it is
possible for the CT proxy to manipulate the URI, then we will
say that the proxy has to maintain security pending that we
find some tests that we can test the CT proxy with.
Francois: What we are saying is
that the CT proxy becomes a web browser and has to be tested
like a web browser.
... I don't think that these tests cover security.
Rob: Maybe the Opera guys have some security tests.
<Jo> PROPOSED RESOLUTION: Since there doesn't appear to be a way in which the URI sent to the User Agent can be manipulated to preserve security it is permissible for a CT proxy to act on content in so that security is nonetheless preserved as adjudged by conformance tests that are to be researched. If no such security tests can be found then there cannot be conformance associated with link...
<Jo> ...rewriting and it cannot be permissible for CT proxies to do so.
<Jo> PROPOSED RESOLUTION: Since there doesn't appear to be a way in which the URI sent to the User Agent can be manipulated to preserve security related to same origin policies it is permissible for a CT proxy to act on content in so that security is nonetheless preserved as adjudged by conformance tests that are to be researched. If no such security tests can be found then there cannot be...
<Jo> ...conformance associated with link rewriting and it cannot be permissible for CT proxies to do so.
<DKA> +1
Rob: Is it worth mentioning what tests were are looking for--JavaScript and cookies?
<EdC> I would replace "to do so" with "to rewrite links in such a way that they do not preserve domain origin distinction" (other URL rewriting that preserve it being ok in principle).
Rob: and DOM?
<rob> +1
<Bryan> +1
Francois: What else could there be? I think just cookies and scripts.
<francois> +1
<Jo> +1
<EdC> +1
Francois: Just so I understand, if we can't find tests then we won't allow link rewriting.
Jo: Yes.
+1
<Jo> +1
<JonathanJ> +1
RESOLUTION: Since there doesn't appear to be a way in which the URI sent to the User Agent can be manipulated to preserve security related to same origin policies it is permissible for a CT proxy to act on content in so that security is nonetheless preserved as adjudged by conformance tests that are to be researched. If no such security tests can be found then there cannot be conformance associated with link rewriting and it cannot be permissible for CT proxies to do so.
Francois: Could be linked to HTML 5; they are the ones defining same origin.
<Jo> ACTION: daoust to ascertain the availability of tests that ensure that same origin policy conformance, when implemented in this way, can be tested [recorded in http://www.w3.org/2009/03/26-bpwg-minutes.html#action02]
<trackbot> Created ACTION-925 - Ascertain the availability of tests that ensure that same origin policy conformance, when implemented in this way, can be tested [on François Daoust - due 2009-04-02].
<francois> [FWIW, the following page seems to be pretty complete on same origin policy and security settings: http://code.google.com/p/browsersec/wiki/Part2#Standard_browser_security_features ]
DKA: Let's move on to the next resolution.
<Jo> PROPOSED RESOLUTION: Interception of HTTPS is not permissible without consent from the user on a case by case basis
Jo: We need to agree on what Case-by-case basis means.
Bryan' text: Here is the proposed informative text "Link rewriting is always used by CT Proxies that are accessed as an origin server initially, e.g. which provide mobile-adapted web search and navigation to the web pages returned in the search results, or to which the browser is redirected through the CT Proxy for adaptation of a web page. Link rewriting *may* be used by CT Proxies acting...
scribe: as normal HTTP proxies (e.g. configured or transparent) for the browser, but may not be required since all browser requests flow through the CT Proxy."
Jo: Why don't include that as a note under link rewriting?
Bryan: OK
<Jo> PROPOSED RESOLUTION: Include text on the following lines as a note under a section on Link Rewriting: "Link rewriting is always used by CT Proxies that are accessed as an origin server initially, e.g. which provide mobile-adapted web search and navigation to the web pages returned in the search results, or to which the browser is redirected through the CT Proxy for adaptation of a web page....
<Jo> ...Link rewriting *may* be used by CT Proxies acting as normal HTTP proxies (e.g. configured or transparent) for the browser, but may not be required since all browser requests flow through the CT Proxy."
<EdC> +1
<Bryan> +1
<JonathanJ> +1
+1
<Jo> +1
<rob> +1
<DKA> +1
<adam> +1
Francois: I am at a bit of a loss on this resolution. The other resolution still stands, right.
<francois> +1
RESOLUTION: Include text on the following lines as a note under a section on Link Rewriting: "Link rewriting is always used by CT Proxies that are accessed as an origin server initially, e.g. which provide mobile-adapted web search and navigation to the web pages returned in the search results, or to which the browser is redirected through the CT Proxy for adaptation of a web page. Link rewriting *may* be used by CT Proxies acting as normal HTTP proxies (e.g. configured or transparent) for the browser, but may not be required since all browser requests flow through the CT Proxy."
<Jo> PROPOSED RESOLUTION: Interception of HTTPS is not permissible without consent from the user on a case by case basis
Jo: What does case-by-case basis mean?
Jo: What we are trying to avoid with "case-by-case basis" is blanket preferences and also making the user do nonsensical things.
<Jo> PROPOSED RESOLUTION: Interception of HTTPS is not permissible without explicit prior agreement from the Content Provider
<Jo> [we need to solve the next Proposed resolution prior to the previous]
Jo: Let's look at the next resolution because the case-by-case problem won't exist if we take the next resolution.
DKA: If we are viewing the CT proxy as the browser, then this HTTPS resolution doesn't make sense.
Francois: Earlier we decide that a CT proxy is a distributed browser.
Bryan: On Jo's proposed resolution, are we only including resolutions that are testable? I don't think explicit prior agreement is testable.
DKA: I don't think that it even makes sense. A bank is one thing, but what about other types of transactions?
Jo: It is impossible to second-guess a CP's use of HTTPS. They want a secure transaction.
DKA: I don't see that this is testable or scalable. I agree with Bryan.
Jo: Then you would say that the resolution must be taken and can't use non-testable as a cop out.
DKA: What do others think?
Eduardo: As a CP, I have an expectation that there will be security. I'm going to break it, I'm not going to even tell you about.
DKA: What about Opera Mini, SkyFire?
Francois: There is tight integration between client and server.
DKA: You should still hijack the Opera server.
Rob: Could happen on Firefox as well.
DKA: If you assume that all of the actors in the chain are well behaved, then what we are really talking about is malware somewhere in the chain.
Kai: When HTTPS is used, it is carefully chosen. There is a performance loss. It is used when we mean it. It shouldn't be mucked with. There are serious legal concerns.
DKA: We talked about Opera Mini.
Jo: Out of scope of this document.
DKA: There is the opportunity for malware even on a desktop browser.
Jo: Are you saying that because there are opportunities for malware, why not introduce more?
DKA: If you assume that the actors are benign, then what we are talking about malware.
Jo: I don't agree. We are saying that the CP doesn't want anyone to listen in.
Kai: Obtaining permission from the origin server means that the CT proxy goes out of scope.
Francois: The only reason to
allow HTTPS link rewriting is to allow good user
experience.
... You are not honoring the spirit of HTTPS.
DKA: So one reason not to allow
HTTPS link rewriting would be because the user couldn't examine
the certificate.
... You might not be able prevent phishing attacks.
<Zakim> Bryan, you wanted to ask if this is testable and to point out dependency upon domain validation for downloaded or signed objects
Rob: You could allow the user to see the real certificate through some UI.
Bryan: You have the same trust
issues as with the scripts and cookies and some domain
stuff.
... I can be downloading content for use outside the browser
and the trust might be broken because I downloaded it through
the proxy.
Rob: That comes back to the link-rewriting argument.
Eduardo: There might be some cases where HTTPS could be used--on phones where the cert handling might be broken.
DKA: I'm warming to requiring consent for HTTPS link rewriting; it's just web breaking.
Rob: What about the long tail where there is HTTPS but no mobile site.
DKA: How about giving a strongly worded warning to the user that their connection is not secure?
Francois: Because it is not necessarily up just to the user.
DKA: What about if I give someone my password? Then the CP is not necessarily talking to the real user.
Rob: True. It is usually the user's responsibility to take on the risk.
Francois: What about banks that don't allow CT proxies to intervene?
DKA: Well, there is no reason that CT proxies couldn't be more restrictive that what we say.
Kai: The CP is selecting HTTPS, and it shouldn't be changed.
Rob: What the CP is saying is that I'm providing a secure connection to your PC, and it's the user's choice to have a distributed browser.
Francois: There is no way for the CP to refuse the choice.
Kai: no-transform?
Francois: But it is already too late?
Rob: The HTTPS request should have a via header that would not normally be there.
<DKA> PROPOSED RESOLUTION: It's enough to get the user's consent (in response to a strongly worded warning) in order for proxies to transform https content.
Francois: That is not enough.
Eduardo: As a CP, I would not feel comfortable with this. Also, the legal framework could be a problem.
DKA: We can't always say "don't do this if it is illegal"
<DKA> PROPOSED RESOLUTION: Proxies must never transform https content unless a prior agreement has been reached with the specific origin server.
<EdC> Change "I feel comfortable" with "I do not feel conformtable".
<Zakim> Bryan, you wanted to state we should not require such a consent to be real-time or explicit
Bryan: Getting user consent on a
case-by-case basis will really bug users and they'll give up.
If you are doing it often, it's going to break.
... We've had significant problems with HTTPS and the way it is
used and prompting the user.
Kai: I would second that. You might have to do it for every asset on the page.
<DKA> PROPOSED RESOLUTION: It's enough to get the user's consent on https session set-up (in response to a strongly worded warning) in order for proxies to transform https content.
Rob: The user can give their consent in real time. The HTTPS link stays up for a long time.
<Bryan> for the minutes: "We've had significant problems with HTTPS" should be "We've seen significant issues with interrupting the normal flow of applications using HTTPS"
DKA: You would have a strong warning that required consent. You might really need to get to your bank.
Kai: Users try to avoid that
popup. It happens when secure content is mixed with insecure
content.
... What is more important that users know they are leaving a
secure connection;.
DKA: What is really important is that the user knows that the HTTPS connection is going through a CT proxy.
Kai: Are user's going to understand the implications of this?
DKA: If the user trusts Vodafone, then the user may want the HTTPS link through the CT proxy.
Kai: What about some unknown company?
DKA: Then the user can refuse.
Rob: There is the long tail where there are websites that have been written long ago that provide HTTPS.
<DKA> PROPOSED RESOLUTION: Proxies must never transform https content unless a prior agreement has been reached with the specific origin server.
<inserted> scribenick: adam
Rob: It's not a symetric agreement. The server knows nothing about the user's identity.
francois: Technically, yes, but the impression is that it's symmetrical.
DKA: We need to draw this to a close.
Kai: I don't want anybody else to
do anything with my https content. It's secured content.
... Supportive of the resolution.
<SeanP> -1
<rob> -1 because this is not scalable to even a thousand long-tail websites that may use HTTPS for log-in
<Kai> +1
<EdC> +1
<Bryan> +1
<Jo> +1
<francois> +1 (because something's missing in the technology stack to enable that)
Bryan: We're not saying anything about the verifiability of such agreement
<Kai> of course, if there is an agreement it is out of scope of this document :-)
Bryan: Unless there is some kind of agreement with both origin server and user, then you shouldn't transform. It doesn't have to be realtime or explicit though.
DKA: Yes, but this resolution says: *never*.
rob: This resolution is about the consent of the origin server. The consent of the user is separate resolution.
DKA: Yes, but if we pass this
resolution then we'll never encounter the other one in
reality.
... This would mean that a lot of existing implementations are
not-compliant.
kai: Perhaps rightfully so.
... Can the intermediary be trusted not to do anything with the
secured data?
Rob: Assuming we don't pass this resolution because it's a "never", we may pass one that says "may" in which case it's the user's choice to trust the intermediary.
<DKA> PROPOSED RESOLUTION: Proxies may transform https content in the cases where there is a pre-existing agreement between the proxy operator and the source or in the case where user consent has been given on a warning provided at the beginning of the https setup.
<Jo> -1
<francois> -1
Rob: There's two sides to it. Does the CP agree? Does the user agree? But because with this resolution there's no way for the content providers to agree the user will never get a choice.
<EdC> -1
DKA: This is the opposite resolution.
SeanP: So there will be a warning every time?
<Bryan> -1 the user consent should be required no more often than once per browsing session, and should be able to apply to all sites accessed through the CT proxy in that session
DKA: The warning will be each time the user starts a session.
<Kai> -1 because an agreement between user and proxy operator may still hold the CP responsible, which is untenable
<Jo> [two party consent is required and can't be achieved]
DKA: Disagree with "CT proxy session" -- my decision to trust the CT depends on the sites I am interacting with.
Kai: If the CP has decided his content needs to be secured, but this security is compromised by intermediary (because there is an agreement with the user) then the CP might still be held responsible.
[ Discussion on whether a bank (for example) would be happy with this proposal ]
DKA: We don't want to weaken the perceived security of mobile internet.
Jo: May be pragmatic to transform https content without consent of CP, but can't be a BP.
<DKA> PROPOSED RESOLUTION: We will remain silent on https content rewriting.
<DKA> PROPOSED RESOLUTION: We will identify https transformation as a feature at risk - something you can remove from the document.
Francois: Could mark it as a feature at risk, we may have to remove this recommendation if we can't implement it.
<francois> Definition of a feature at risk
Jo: If we allow https transformation we leave CP with no way of saying: "I don't want this to happen."
dka: Could we give the origin
server a way to tell the origin server on set-up that I don't
want you to transform https content.
... What happens on the handshake when the ct proxy establishes
the connection with the origin server?
Bryan: SSL handshake between CT
Proxy and origin server.
... But the origin server has no way to know that this is
coming from the proxy and not from a browser.
Rob: You could put in a via header... But that's after the SSL is established.
DKA: At that point (on seeing the first HTTP request on the SSL connection with a via) can return a 403 and close. And the CT Proxy knows that the origin server doesn't want to establish an SSL connection.
Kai: So the via header is required.
Jo: Yes.
DKA: Is this the middle-way we want? The control is back on the server.
Francois: But legacy content that doesn't know about this will quietly get opted-in.
Jo: Two party consent is fundamental principle. But this isn't two party consent -- it's one party consent and one party ignorance.
DKA: This doesn't break two party consent.
Kai: The server has an opportunity to refuse because it sees the header.
<EdC> 3 issues: (1) only opt-out for CP, no opt-in (silence == accept https break). (2) We assume via header fields never get suppressed ior transit (3) We are implicitly specifying a protocol for https: first establish tsl/ssl session, then check http via -- I can already foresee the broadsides of the IETF.
<DKA> PROPOSED RESOLUTION: We will remain silent on https content rewriting.
Kai: Is the user protected from unwanted manipulation?
DKA: None of this prevents bad proxies / malware.
Kai: The goal we are trying to acheive is measure conformance to this document.
DKA: There isn't much consensus. The weight of opinion is on explicitly disallowing https transformation.
<DKA> PROPOSED RESOLUTION: Proxies must never transform https content unless a prior agreement has been reached with the specific origin server.
Francois: We've already had significant feedback saying please don't allow HTTPS link re-writing.
Rob: We could say that proxies may transform (subject to user consent) and mark it as a feature at risk.
Jo: Feature at risk is only valid on the grounds of implementation experience -- if it turns out to be unviable.
Rob: We shouldn't remain silent. We have things to say about user consent and should note that there is no way for the origin server to consent.
DKA: That sounds like an informative statement. Remain silent means: No normative statement.
Jo: I think it would look strange.
<DKA> PROPOSED RESOLUTION: Proxies may transform https content in the cases where there is a pre-existing agreement between the proxy operator and the source or in the case where user consent has been given on a warning provided at the beginning of the https setup.
EdC: Replace "or" with "and" and I agree.
<Bryan> -1 we should not mandate the "at the begginning..."
Bryan: Don't want to make statements about when consent is provided since it can have unforeseen effects.
SeanP: Agree with Bryan, user experience might not be good.
Rob: If we go with a resolution like this a number of resolutions on when consent is provided is likely to follow.
<Bryan> I suggest "... or in the case where user consent has been given by prior agreement or in response to a warning provided by the CT Proxy"
<Jo> PROPOSED RESOLUTION: Two party consent is required for HTTPS link rewriting
<DKA> PROPOSED RESOLUTION: Proxies may transform https content in the cases where there is a pre-existing agreement between the proxy operator and the source or or in the case where user consent has been given by prior agreement or in response to a warning provided by the CT Proxy.
<SeanP> +1 to the last one
<EdC> -1 same issue: "and" instead of "or"
<Kai> -1 it continues to leave the CP being responsible
<Kai> +1 to Jo's proposal
<rob> +1 if it is legally OK to have one-party consent
<Jo> PROPOSED RESOLUTION: Per OPES two party consent is required for HTTPS link rewriting (by the content provider and the user)
<Bryan> my core opinion on this is that HTTPS link rewriting will end up breaking sites and is a bad idea in general, but I would not want to restrict someone's ability to solve that challenge
<DKA> PROPOSED RESOLUTION: Proxies must never transform https content unless a prior agreement has been reached with the specific origin server.
<Bryan> +1
<Kai> +1
<Bryan> I want breakfast
<SeanP> -1
<francois> +1
<EdC> +1
<rob> -1
<DKA> +0
<Jo> +1
0
RESOLUTION: Proxies must never transform https content unless a prior agreement has been reached with the specific origin server.
Note inserted after the meeting: the above resolution has been revised during the following day of the F2F after another discussion on OPES and two-party consent. See the corresponding topic and resolution in the minutes of day 3.
<JonathanJ> 0
<achuter> +0
Rob: This will give us trouble with reference implementations.
<Jo> [adjourned]
SeanP: from a practical sense,
nearly every deployment Novarra's done has involved HTTPS
rewriting
... and those that didn't it was asked for later
DKA: this is a victim of dogma over common sense
<Bryan> Sean, do the deployments act as a transparent or configured proxy?
<SeanP> Both
EdC: My presence here at this meeting is partly sponsored by dotMobi
<EdC> All my thanks to dotMobi to allow me to participate in the F2F meeting.
Jo: I think we can close this
DKA: do we need any further resolutions to close this?
francois: we can link the action to the issue
Jo: under sec 4.2.9 of the CTG
draft we have the heuristics
... the resolution is a SHOULD take account of these
heuristics. So they are no longer heuristics
... Is there a textual change to make here?
francois: the examples are no longer examples but a list of things that unambiguously make a page mobile-aware
<francois> minutes on mandating heuristics
francois: and the other things in the appendix remain examples of heuristics that could also be taken into account of under undocumented circumstances
Jo: ok, so I'll reword 4.2.9
DKA: So we still have some non-mandatory heuristics
francois: These could create confusion if people expect that following them will result in certain actions
<Jo> ACTION: Jo to inser sections under proxy decision to transform a. to specify SHOULD NOT in the presence of the features listed at http://www.w3.org/2009/03/10-bpwg-minutes.html and b. to include the current cullets listed as heuristics [recorded in http://www.w3.org/2009/03/26-bpwg-minutes.html#action03]
<trackbot> Created ACTION-926 - Inser sections under proxy decision to transform a. to specify SHOULD NOT in the presence of the features listed at http://www.w3.org/2009/03/10-bpwg-minutes.html and b. to include the current cullets listed as heuristics [on Jo Rabin - due 2009-04-02].
francois: but it's just a
probable
... and we've already seen in the past examples of "W3C said
..." quotes out of context
<DKA> PROPOSED RESOLUTION: We delete all non-normative heuristics and close issue-288
<DKA> PROPOSED RESOLUTION: We delete non-normative heuristics except for doctypes and close issue-288
<DKA> PROPOSED RESOLUTION: We delete all non-normative heuristics and close issue-288.
<francois> +1
DKA: it's not our job to tell CT-proxy vendors how to do everything
Jo: but a domain name of *.mobi is a very good indication we should keep
francois: In theory it's not although in practice it is
Jo: what about the TAG finding that URIs should be "meaningful"?
francois: your point is valid as a good practice
SeanP: the mandatory ones are SHOULD, can the rest be MAY?
francois: different levels of SHOULD, MAY, might, could... are confusing
Jo: I'll try to find this TAG advice
<Jo> TAG FINDING: Good Practice: URIs intended for direct use by people should be easy to understand, and should be suggestive of the resource actually named.
<Jo> --> http://www.w3.org/2001/tag/doc/metaDataInURI-31.html TAG FINDING on Metadata in URIs
Rob: but the use of different User-Agents to view content isn't always relevant to the direct-use-URI
<Jo> PROPOSED RESOLUTION: Add .mobi to the list of mandatory heuristics as it is a stronger indication of mobile intent than many of the content-types and DOCTYPEs already agreed
francois: is there a reference (eg .mobi charter) we can use?
<Jo> PROPOSED RESOLUTION: Add .mobi to the list of mandatory heuristics as it is a stronger indication of mobile intent than many of the content-types and DOCTYPEs already agreed - other URI patterns are more ambiguous as to their intent
<Bryan> oops - need a new bridge code?
Kai: are there dotmobi constraints that guarantee this?
Jo: Yes, there are compliance rules with the company dotmobi to take out a *.mobi domain name
+1
<DKA> +1
<achuter1> +1
<EdC> +1
<Jo> [am conflicted so 0]
<JonathanJ> +1
<Bryan> +1
<Kai> 0
<francois> 0 (note there could be a vendor-neutrality problem on top of the Web arch possible push-back)
RESOLUTION: Add .mobi to the list of mandatory heuristics as it is a stronger indication of mobile intent than many of the content-types and DOCTYPEs already agreed - other URI patterns are more ambiguous as to their intent
<SeanP> 0
<Bryan> what about "m.domain" type hostnames?
francois: I think we shouldn't even mention the rest that are not SHOULDs
EdC: but combinations such as application/xhtml+xml AND http://m.* will actually be good practice
francois: but it doesn't give the content-provider any guarantees
EdC: they are ambiguous but they are in use
SeanP: I don't see a big problem leaving them in a non-normative appendix
jo: are we abandoning the list in 4.2.9?
francois: apart from the agreed SHOULD parts, yes
<Bryan> Which version is 4.2.9 in? Can someone past a URI to the draft?
francois: the rest either delete or move to an appendix
jo: even the mobileOK Basic confomance mark?
<DKA> PROPOSED RESOLUTION: close issue-288 and move on.
Rob: it's a feature-at-risk because there is currently no standard machine-readable trustmark
<Bryan> Can we say which bullets in "Examples of heuristics:" (in 4.2.8 in 081107) are being removed?
<DKA> PROPOSED RESOLUTION: We delete all non-normative heuristics and close issue-288.
<Bryan> Which ones are "non-normative"?
<francois> +1
Jo: ok, let's just remove the non-mandatory items
<SeanP> 0
0
EdC: even remove the line "the user-agent has features ... to allow it to present the content"?
francois: yes because User-Agent was considered at the HTTP Request stage
jo: but it could also be considered in conjunction with the content of the response
<Jo> --> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/090313 Current Draft
francois: but that is difficult
to test
... eg the user-agent can render tables but it may be so wide
as to be unviewable
Rob: as Kai points out there's definitely no best-practice here
<DKA> PROPOSED RESOLUTION: We delete all non-normative heuristics and close issue-288.
<francois> +1
<Jo> +1
<DKA> +1
0
RESOLUTION: We delete all non-normative heuristics and close issue-288
<DKA> CLOSE ISSUE-288
<trackbot> ISSUE-288 Should the Content Transformation Guidelines include a non normative list of non-mandated mobile heuristics? closed
<DKA> PROPOSED RESOLUTION: Close Issue-284
<DKA> +1
+1
<francois> +1
<EdC> +1
<DKA> CLOSE ISSUE-284
<trackbot> ISSUE-284 W3C mobile addressing standards closed
RESOLUTION: Close Issue-284
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/open
DKA: haven't we already talked about "content selection" which isn't "content transformation" but is about selecting suitable content for the user's situation
francois: then you're already mobile-friendly enough that the CT-proxy has nothing to adapt
DKA: what if there is something that needs adapting?
EdC: like what?
SeanP: there are cases where altered headers might be sent first, then what?
francois: Then the Vary: User-Agent header can be used to indicate there was alternate content available
<achuter1> scribenick: achuter1
<DKA> ScribeNick: achuter1
<DKA> Scribe: Alan
Fran�ois: Headers can be interpreted only on basis of prior experience
Fran�ois: Often no way to get original UA header.
Jo: Knowing that there is a mobile present, user requests desktop version
EdC: We need the x-device header
<Jo> PROPOSED RESOLUTION: Leave X-Device headers in as they add value
EdC: then the provider can know what the requester really is.
<francois> -1
<Jo> PROPOSED RESOLUTION: Leave X-Device headers in as they add value and close ISSUE-289
<SeanP> +1
<francois> -1
Fran�ois: I would like to take them out
<rob> 0
<EdC> +1
<DKA> +1
<Jo> [francois explains that his -1 is a formal objection and is not to be taken seriously]
RESOLUTION: Leave X-Device headers in as they add value and close ISSUE-289
<DKA> CLOSE Issue-289
<trackbot> ISSUE-289 Should CT proxies send X-Device-* headers after having determined the content is not mobile-optimized? closed
<DKA> ACTION-830?
<trackbot> ACTION-830 -- Bryan Sullivan to review correspondence with Dennis cf LC-2065 and to draft a) proposed changes to the document and b) a proposed response to Dennis -- due 2008-09-09 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/830
<francois> [I think the real problem to solve is the availability of the original HTTP request, and that, once this is solved, there is no strong use case to have the origin HTTP header fields along with altered ones.]
Bryan: would be provided by implementation
<SeanP> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2065?cid=2065
dan: How to respond to LC 2065
Bryan: had resolution that was partial agreement with this.
Dan: LC 2065 says that CT proxy
must allow user possibility of obtaining transformed version,
but our document gives a should not a MUST.
... LC 2065 secxond point in list says CT proxies must allow
users possibility to turn off transformation.
<Jo> CLOSE ACTION-830
<trackbot> ACTION-830 Review correspondence with Dennis cf LC-2065 and to draft a) proposed changes to the document and b) a proposed response to Dennis closed
<DKA> PROPOSED RESOLUTION: Regarding LC-2065 write back to Dennis that we agree and we think sections 4.2.2 and 4.2.9 of current draft (1q) accomodate this.
<DKA> +1
<EdC> +1
<DKA> RESOLUTION: Regarding LC-2065 write back to Dennis that we agree and we think sections 4.2.2 and 4.2.9 of current draft (1q) accomodate this.
<Bryan> Section "4.2.9.1 Alteration of Response" says "If a proxy alters the response then: ... It should indicate to the user that the content has been transformed for mobile presentation and provide an option to view the original, unmodified content.". This meets the intent but not the requirement level as requested.
<DKA> ACTION-850?
<trackbot> ACTION-850 -- Bryan Sullivan to provide some text on whitelists to see if we can include them somehow and come to an agreement re. LC-2003 -- due 2008-09-29 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/850
Jo: About Action 850
<DKA> LC-2003?
<Jo> --> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/850 ACTION-850
Bryan: do we really need to say anything about whitelists?
<DKA> CLOSE ACTION-850
<trackbot> ACTION-850 Provide some text on whitelists to see if we can include them somehow and come to an agreement re. LC-2003 closed
Jo: Action was attempt to reintroduce it.
<francois> ACTION-858?
<trackbot> ACTION-858 -- Sean Patterson to find out if novarra has figures on whether users choose to proceed at the HTTPS interstitial page -- due 2008-10-13 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/858
<DKA> CLOSE ACTION-858
<trackbot> ACTION-858 Find out if novarra has figures on whether users choose to proceed at the HTTPS interstitial page closed
<DKA> ACTION-867?
<trackbot> ACTION-867 -- François Daoust to look into an appendix with relevant normative statements of RFC2616 and report back to the group. -- due 2008-10-27 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/867
<DKA> CLOSE ACTION-867
<trackbot> ACTION-867 Look into an appendix with relevant normative statements of RFC2616 and report back to the group. closed
<DKA> ACTION-886?
<trackbot> ACTION-886 -- Jo Rabin to propose beefed up text on heuristics in respect of practice vs good practice -- due 2008-12-02 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/886
<DKA> CLOSE ACTION-886?
<DKA> CLOSE ACTION-886
<trackbot> ACTION-886 Propose beefed up text on heuristics in respect of practice vs good practice closed
<DKA> ACTION-887
<DKA> ACTION-887?
<trackbot> ACTION-887 -- Jo Rabin to put a reference somewhere to the Best Practice about exploiting device capabilities -- due 2008-12-02 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/887
<DKA> CLOSE ACTION-887
<trackbot> ACTION-887 Put a reference somewhere to the Best Practice about exploiting device capabilities closed
<DKA> ACTION-889?
<trackbot> ACTION-889 -- Jo Rabin to take the editorial comments in http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0019.html into account for next version of the draft -- due 2008-12-09 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/889
<francois> [relevant section removed for ACTION-887]
[Eduardo's comments]
Jo: changed "header fields" to
"value of header fields"
... Will preface the first sentence in 4.1.5
<Jo> ACTION: Jo tpo preface the first sentence in 4.1.5 with Aside from the usual procedures defined in [RFC 2616 HTTP] [recorded in http://www.w3.org/2009/03/26-bpwg-minutes.html#action04]
<trackbot> Created ACTION-927 - Tpo preface the first sentence in 4.1.5 with Aside from the usual procedures defined in [RFC 2616 HTTP] [on Jo Rabin - due 2009-04-02].
<DKA> PROPOSED RESOLUTION: Accept Jo's editorial changes detailed in email 13-March-2009 and close ACTION-927
<DKA> PROPOSED RESOLUTION: Accept Jo's editorial changes detailed in email 13-March-2009 and close ACTION-889
Jo: All Eduardo's comments dealt with.
RESOLUTION: Accept Jo's editorial changes detailed in email
<DKA> CLOSE ACTION-889
<trackbot> ACTION-889 Take the editorial comments in http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0019.html into account for next version of the draft closed
<DKA> ACTION-892?
<trackbot> ACTION-892 -- François Daoust to prepare an ICS with MUST/MUST NOT (to view if that's a good idea), try to add a "depends on" column, explain "Not applicable" or remove it. -- due 2008-12-09 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/892
<DKA> ACTION-893?
<trackbot> ACTION-893 -- Robert Finean to start putting together a set of guidelines that could help address the security issues triggered by links rewriting. -- due 2008-12-23 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/893
<Bryan> Here is my proposed response to 850 (sorry about the line breaks): Re "1. Content transformation proxies...": Section "4.2.9.1 Alteration of Response" says "If a proxy alters the response then: ... It should indicate to the user that the content has been transformed for mobile presentation and provide an option to view the original, unmodified content." Re "2. Content transformation proxies...": this will be addressed by adding text to "4.1.5.3 User Selection of
<Bryan> Restructured Experience": "Proxies SHOULD provide users with the option to enable or disable content transformation, as a preference to be applied until changed." These changes meet the intent but not the requirement level as requested. The reason for the requirement leve difference is that not all CT Proxies may be capable of retaining user preferences.
<DKA> ACTION-850?
<trackbot> ACTION-850 -- Bryan Sullivan to provide some text on whitelists to see if we can include them somehow and come to an agreement re. LC-2003 -- due 2008-09-29 -- CLOSED
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/850
<DKA> ACTION-893?
<trackbot> ACTION-893 -- Robert Finean to start putting together a set of guidelines that could help address the security issues triggered by links rewriting. -- due 2008-12-23 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/893
Rob: Was about man-in-the-middle security
Jo: Can't have a BP that requires a security audit.
<DKA> CLOSE ACTION-893
<trackbot> ACTION-893 Start putting together a set of guidelines that could help address the security issues triggered by links rewriting. closed
Jo: Now a moot point after the link rewriting resolution.
[break now]
<DKA> [resuming]
<francois> Scribe: Kai
<DKA> ACTION-896?
<trackbot> ACTION-896 -- François Daoust to stimulate discussion on the SHOULD NOT question ref mobile heuristics -- due 2009-01-20 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/896
<DKA> CLOSE ACTION-896
<trackbot> ACTION-896 Stimulate discussion on the SHOULD NOT question ref mobile heuristics closed
<DKA> ACTION-900?
<trackbot> ACTION-900 -- Jo Rabin to raise issues on inconclusive CT threads once the new draft of CT is prepared -- due 2009-01-27 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/900
<DKA> ACTION-901?
<trackbot> ACTION-901 -- Sean Patterson to raise issue the thread he started on transforming mobile content entitled \"RE: [minutes] CT Call 6 january 2009\" -- due 2009-01-27 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/901
SeanP: I think it is done
<francois> http://www.w3.org/2009/01/20-bpwg-minutes.html#item04
<DKA> CLOSE ACTION-901
<trackbot> ACTION-901 Raise issue the thread he started on transforming mobile content entitled \"RE: [minutes] CT Call 6 january 2009\" closed
<DKA> ACTION-902
<DKA> ACTION-902?
<trackbot> ACTION-902 -- Jo Rabin to summarise current discussions on https link re writing -- due 2009-01-27 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/902
<DKA> CLOSE ACTION-902
<trackbot> ACTION-902 Summarise current discussions on https link re writing closed
<DKA> ACTION-912?
<trackbot> ACTION-912 -- Eduardo Casais to suggest some new wording on X-Device-* HTTP header fields keeping the normative meaning but noting that we're working with IETF and may deprecate this in the future -- due 2009-03-10 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/912
<EdC> http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0058.html
EdC: this has not been resolved on a call
Jo: I have added some text to EdC proposed text
<Zakim> francois, you wanted to report on discussion with IETF
Jo: do you, EdC, have a problem with my text
EdC: no
francois: i was asked to join a
liaison call with IETF
... the point was not to talk about it being a good or bad
idea, but how to register such a header field, when it has
already been implemented.
... it can be grandfathered in. It is too late and we don't
want to add more confusion we can choose the most recent
deployed one and it should be accepted by IETF
... we need solid use cases. On the naming we can move forward
with the X- prefix
<DKA> PROPOSED RESOLUTION: adopt the text as proposed bt Eduardo and modified by Jo regarding X- prefix.
<DKA> PROPOSED RESOLUTION: adopt the text as proposed bt Eduardo and modified by Jo regarding X- prefix and close ACTION-912
francois: in the guidelines we will have a normative statement to use headers which we will not register. I think that will be hard to move forward.
Jo: what is the problem here?
francois: the header fields need
to be registered in the IANA DB
... if we will have an objection we will have to convince them
we need them
Jo: is that really necessary?
francois: there are two levels of registration. One is simple and does not require support by the IETF
EdC: there will be discussion
francois: they should appear in some list and moving them to the repository will then be harder
Jo:
francois: we already recevied
comments that this should not be in a W3C draft
... we should action somebody to register this on the temporary
registry
... to envoke grandfathering we need to find out how uses these
header fields
rob: I think we can use them. It is default, but in practice they don't
Jo: can we ask francois to do this, knowing that we may run out of time to finish this
francois: I am not sure I agree.
We cannot really move forward on something that is not fully
defined
... if we use it we must define it
EdC: you ask to go through a process that make them deprecated and then have them removed
francois: IETF and W3C work closely together and they have already said this is not our task so if we don't go through the process we will just get the same answer
<DKA> PROPOSED RESOLUTION: adopt the text as proposed bt Eduardo and modified by Jo regarding X- prefix, we will register the header with IETF and close ACTION-912
EdC: there are some fields that have been temporary for a long time
SeanP: they also recommed X-forwarded
francois: it is related to proxy
in general
... it has nothing to do with transformation
DKA: look at the proposal please
SeanP: what is difference between edc and jo's text/
EdC: Jo said we may or may not committ...
<EdC> +1
<rob> +1
<francois> 0
<DKA> +1
<DKA> +2
<SeanP> +1
RESOLUTION: adopt the text as proposed bt Eduardo and modified by Jo regarding X- prefix, we will register the header with IETF and close ACTION-912
<Jo> ACTION: daoust to progress registration of the X- headers irrespective his personal distate for the subject [recorded in http://www.w3.org/2009/03/26-bpwg-minutes.html#action05]
<trackbot> Created ACTION-928 - Progress registration of the X- headers irrespective his personal distate for the subject [on François Daoust - due 2009-04-02].
<DKA> ACTION-925?
<trackbot> ACTION-925 -- François Daoust to ascertain the availability of tests that ensure that same origin policy conformance, when implemented in this way, can be tested -- due 2009-04-02 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/925
<DKA> CLOSE ACTION-912
<trackbot> ACTION-912 Suggest some new wording on X-Device-* HTTP header fields keeping the normative meaning but noting that we're working with IETF and may deprecate this in the future closed
francois: so far I found out that
no two browsers behave the same
... what you can do with a client script depends on the
browser
Jo: Matt points out the abstract is wrong and incomprehensible
Jo: Matt points out the abstract
is wrong and incomprehensible
... we were told not to tell transforming proxy providers how
to do their work
DKA: there could be informative
guidance
... somebody want to write a good abstract?
EdC: I'll do it
... with the gist of what is here and that it provides
informative guidance
Jo: leave out the informative
<DKA> ACTION Eduardo to write an abstract for CT.
<trackbot> Created ACTION-929 - Write an abstract for CT. [on Eduardo Casais - due 2009-04-02].
Jo: we'll leave that with
Eduardo
... next point is not completely implemented resolutions
... [going into LCs]
Jo: we wanted to change something
in the scope section
... do we need to maintain these definitions? We did not define
these concepts very formally because they are used
lightly.
... making the distinction is good
[we are talking about 2.2]
jo: i thought the mandatory
heuristics mean that a no tranform is implied
... but it is not
<Jo> PROPOSED RESOLUTION: Ref LC-2050 RESOLVE NO to expanidng the definitions and leave defininitons in place
<rob> +1
<SeanP> +1
RESOLUTION: Ref LC-2050 RESOLVE NO to expanidng the definitions and leave defininitons in place
Jo: i put in a note here [reading
note]
... rather than what I was mandated to do
... resolution was already taken
Jo: Resolution was taken
francois: I did provide this and
can reprovide
... Jo has already reinserted it
... it was on receiving http headers
Jo: so no further action required
[viewing the LC]
Jo: what did we resolve?
[viewing]
Jo: is this clear without a
diagram?
... if I add one will it help?
... perhaps we should scrap the idea
EdC: is there a text on what it is called?
Jo: yes there is
[viewing]
1.3 Scope
Jo: [mumbles into his non existing
beard as he reads the section
... no action]
DKA: we clarified that yesterday
EdC: it seems closely linked ot hte normative heuristic
Jo: lets close it
Jo: LC-2040 done
DKA: should we send a note to the commenter?
francois: by the time we send the response we will be done
Jo is mumbling again
[viewing]
DKA: we do this
EdC: section 4.1.3 is completely different
francois: we discussed this in
Mandeljeu
... we removed the normative part on detecting http browser
request
... we are now talking about it in a normative way
Jo: the resolution then seems to
have changed
... all done
Jo: I put some wording in
... we need to review
... we were asked to note that we refer to IAB, about two party
consent
... which we did
... is not really dangling then
Jo: about the CT Doc missing a statement about role of main parties ...etc.
Jo: we used to say in the doc in
previous version that the principles operate similar to
CSS
... in that the user can override
SeanP: I found the
statement
... it was in June
<francois> CT former draft with control
[viewing coupled with mumbling]
Jo: I thought we had something about CSS
<SeanP> http://www.w3.org/TR/2008/WD-ct-guidelines-20080414/#sec-control-conflicts
Jo: if nobody thinks it's useful lets move on
DKA: I think it would be useful
in the intro
... especially with regard to respect to each others
choices
<Jo> ACTION: Jo to write something in the introduction about respect for CP prefgernces, respect for user preferences and the CP's ultimate sanction on the degree of preference they are willing to accommodate [recorded in http://www.w3.org/2009/03/26-bpwg-minutes.html#action06]
<trackbot> Created ACTION-930 - Write something in the introduction about respect for CP prefgernces, respect for user preferences and the CP's ultimate sanction on the degree of preference they are willing to accommodate [on Jo Rabin - due 2009-04-02].
jo: done with this then
Jo: we have done some, just making sure...
4.1.5
Jo: goes back a long
way....
... it is more likely that the accept header will cause
heuristic responses
... if we can say that alteration of the UA Header field
doesn't achieve anything then we can leave it
rob: it is hard to prove. Will be in the long tail.
Jo: if the web site adapts in response to the UA header then we should not do anything with it. It is a user preference
rob: during the browser wars this
became common place and they are still there in the long
tail
... it is not in mobile adapted pages
francois: is this just for 406 error code?
jo: if we say you can ignore 406
then what other mechanism do we offer CPs?
... what we are doing is being helpful in saying that a site
needs a browser revision
... we may make it difficult for them
... for example for security reasons a CP may not want to serve
content
... if with a 406 you rewrite the header, what can the CP
do?
DKA: so legitimate uses of 406...
francois: a bit different from the note here
SeanP: this sounds theoretical
EdC: I have done this...and with
a bank
... they did not want to take liability with anything else
francois: is one way out to not allow to change the UA ?
Jo: I don't think it works
DKA: can we say don't pay attention to 406?
Jo: if the CP does not want to serve content to a particular device, proxy etc. what do we anticipate them to do to signal that
DKA: ideally send a 406, in
reality an errorpage with 200 code
... it is up to the provider or CT proxy provider
rob: in a case where they really don't want to, won't they send a 403?
Jo: we must be careful not remove
choices for CPs
... so we should put a note on using 403 in there
<Jo> ACTION: Jo to insert informative text in the relevant aqppendix describing the use of 403 in declining to server content because of security concerns or whatever [recorded in http://www.w3.org/2009/03/26-bpwg-minutes.html#action07]
<trackbot> Created ACTION-931 - Insert informative text in the relevant aqppendix describing the use of 403 in declining to server content because of security concerns or whatever [on Jo Rabin - due 2009-04-02].
<Jo> ACTION: Jo to specify what he means by the USer Agent editorial note under 4.1.5 [recorded in http://www.w3.org/2009/03/26-bpwg-minutes.html#action08]
<trackbot> Created ACTION-932 - Specify what he means by the USer Agent editorial note under 4.1.5 [on Jo Rabin - due 2009-04-02].
Jo: 4.1.6.1
about the via header
francois: it just shows that there is a CT proxy active
Jo: ok
4.2.9
no it is 4.2.7
Jo: need to do some reorganizing here
4.2.8
Jo: do we also mean other legacy WML content?
francois: in the rest we don't talk about other types, but yes do mean it
EdC: you can only determine the type, but you can't look in it
Jo: remain silent on it then
5.0
seungyun: this section is fine for me (had a question regarding an older version(
Jo: if I am a CP and somebody has a problem with my content I want to find out if they have a problem with my proxy
SeanP: operatos will deploy this...will they want to make it available for anybody
Kai: CPs will not leave this open to the public
seungyun: is transformed content
still mobileOK?
... it should be aligned with mobileOK
Jo: we have touched upon this and then stepped back from it. Difficult to say something meaningful
seungyun: how do we test then?
Jo: we have a conformance claim against this document and the other if you do transform you produce mobileOK content. It would not be good to limit this by combining them.
francois: can you think of a wording to solve this?
Jo: no
SeanP: You can put in something like "reasonable"
<Jo> ACTION: Jo to propose text for section 5 referring to "reasonable terms, timeliness, of access and so on, relating to the use cases of bug determinations, testing and so on [recorded in http://www.w3.org/2009/03/26-bpwg-minutes.html#action09]
<trackbot> Created ACTION-933 - Propose text for section 5 referring to \"reasonable terms, timeliness, of access and so on, relating to the use cases of bug determinations, testing and so on [on Jo Rabin - due 2009-04-02].
I think this section already expresses openness
<Jo> [reasonable and non-discriminatory]
[discussion this needing something to prevent unreasonable hindrances to fulfillment]
Section E
no, D 1.3.2
Jo: this is about thematic
consistency
... bottom line we have a muddle. We need to ask TAG how to
apply this or is the following correct...asking them to clear
up the muddle.
<Jo> ACTION: Jo to try to draft another doc to the TAG about D.1.3.2 [recorded in http://www.w3.org/2009/03/26-bpwg-minutes.html#action10]
<trackbot> Created ACTION-934 - Try to draft another doc to the TAG about D.1.3.2 [on Jo Rabin - due 2009-04-02].
Jo: that's it
rob: I have one more question. Can"t find the reference in OPES about two party consent
francois: OPES states that we
should aim at two party consent but one party consent is
enough
... there are other guidelines, from which Jo infered, that
state two party consent is needed
<francois> http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0052.html
Jo: where to go with this?
EdC: we already did take a resolution on it
rob: the dialog around it mentions two party consent
Jo: I believe as we say later on that one party consent is not enough. so what do they mean by "by itself"?
EdC: does only what opes says has value?
Jo: we can say more but should not contradict it