- From: Francois Daoust <fd@w3.org>
- Date: Tue, 16 Sep 2008 18:07:09 +0200
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Hi,
The minutes of today's call are available at:
http://www.w3.org/2008/09/16-bpwg-minutes
... and pasted as text below.
Resolutions:
- remove "Content Deployment" class of product and move section 4.2
Server Response to Proxy to an informative section. No more normative
guidelines on Content Providers.
- re. LC-2067, state that conformance applies to SHOULD statements as
well. A justification is required for each circumstance in which a
SHOULD statement is not followed. Prepare an Implementation Conformance
Statement to be filled out by Transformation Deployments willing to
claim conformance to the spec.
- Re LC-2050 move definitions to scope to clarify that we are talking
only about restructuring
- re LC-2050 we don't intend to define these concepts any more formally
than we do now
Things to do this week:
- Dream about a cool-and-precise-and-not-so-long title for the spec to
replace "Content Transformation Guidelines". Then Wake up, write it down
and send it to the list!
- Continue discussions on the mailing-list on remaining comments
Francois.
16 Sep 2008
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0025.html
See also: [3]IRC log
[3] http://www.w3.org/2008/09/16-bpwg-irc
Attendees
Present
Francois, hgerlach, jo, andrews, SeanP, Bryan_Sullivan
Regrets
Tom, rob
Chair
francois
Scribe
SeanP
Contents
* [4]Topics
1. [5]Guidelines vs. Protocol
2. [6]LC-2018: on the title
3. [7]LC-2067: conformance to SHOULD
4. [8]LC-2050: restructuring, recoding and optimizing
* [9]Summary of Action Items
_________________________________________________________
<trackbot> Date: 16 September 2008
<francois> Agenda:
[10]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0025.
html
[10]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0025.html
<hgerlach> hi
<hgerlach> Hi
<scribe> scribe: SeanP
<scribe> Scribenick:SeanP
Francois: Short point: The CT task force is not the voice of the
working group.
... we need to go back to the WG to get approval for answers to
comments.
Guidelines vs. Protocol
Francois: Jo, any comments on the responses from Mark and Mark?
Jo: Between a rock and a hard place. Can kind of see their point.
Francois: No matter what we say in the guidelines can be seen as a
refinment of HTTP.
Jo: Not sure what we are supposed to do here. If we say something
that is more strict, are we profiling HTTP?
... when we say something that HTTP doesn't say, that is a kind of
profiling.
Francois: Should we get back to them?
Jo: Baker got back to me; Nottingham didn't.
... Some of this may become a non-issue depending on how things go
in the future.
Heiko: What we are doing is not directly related to HTTP. HTTP is
used as a basis. Could show the HTTP details as an example.
Francois: In 4.6.2 we have a strong statement; have a few other
places where we do this.
Bryan: We are really talking about a service on top of HTTP here.
... We are talking about server behavior on top of HTTP parameters.
... We are focusing on one service: browsing.
Francois: I agree. On possibility mentioned by Jo is remove the
normative statements on the server side and write the section as
more generic advice on how to deal with CT proxies.
... CP want to be able to follow the guidelines without doing
anything.
... Hopefully later changes to the document will address these
problems.
Jo: Seems likely. Maybe we should have a discussion on downgrading
the conformance section.
... I think we are writing a specification about how CT proxies
should behave when using HTTP.
Francois: We have two classes of product: content deployment and
proxy deployment.
... Readers see the conformance statement as something you have to
do; not something you do if you want to conform.
... I think it is fine if we remove the deployment class of products
from conformance.
Jo: It is the job of all CT proxies to work with CP that conform and
those that do not conform. Some restructuring and new text to do
this would be a good idea.
<francois> [to make things clear, we're talking about removing the
"Content Deployment" class of product, and moving section 4.2 to
some other place as an informative section for content providers]
Jo: Idea is downgrading content deployment conformance section;
change it to helpful hints or something like that.
Andrew: The main problem is that we should be stipulating how
servers or CT proxies should be have?
Jo: Not exactly. CT providers are misreading the spec to say that
everyone needs to do this. This point has been misunderstood by some
many people that there is no doubt that the document is not clear.
... The main focus of the document is CT proxies.
Andrew: They are just guidelines.
Jo: We do want something that CT proxies can claim conformance to.
... 2 levels of manditoryness(?). Can claim conformance to
guidelines.
Andrew: There is no way to check conformance. It is up to individual
vendors to claim conformance.
Jo: The question that the deployer would ask the vendor is: Can I
deploy this CT proxy in a conformant manner?
... It is up to the deployer to deploy it in a conformant manner.
<francois> PROPOSED RESOLUTION: remove "Content Deployment" class of
product and move section 4.2 Server Response to Proxy to an
informative section. No more normative guidelines on Content
Providers.
Andrew: I'm happy with this direction.
<jo> +1
<francois> +1
Francois: We chartered the CT guidelines to be normative and now we
are removing normative statements.
<francois> PROPOSED RESOLUTION: remove "Content Deployment" class of
product and move section 4.2 Server Response to Proxy to an
informative section. No more normative guidelines on Content
Providers.
<andrews> +1
<hgerlach> +-0
RESOLUTION: remove "Content Deployment" class of product and move
section 4.2 Server Response to Proxy to an informative section. No
more normative guidelines on Content Providers.
<jo> +cauliflower
Francois: This resolves LC-2007.
LC-2018: on the title
<francois> [11]Sean's proposals
[11]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0009.html
Jo: Shouldn't spend too much time on this, although the title is
important.
Francois: We don't want to put "Mobile" in the title.
... We should select one of the titles.
... Ones that received the most support is Content Transformation:
Guidelines or the long one.
<francois> [Jo's proposal: Content Transformation Proxy
Interoperability Guidelines]
Jo: I made another suggestion.
... I thought it should say something about Interoperability
Heiko: Do we need to highlight that we are transcoding HTML comment?
... Could also do other types of transformation.
Jo: It does include other types of transformation.
Heiko: Other types of transformation are different from what we
discussed earlier.
Francois: I don't think we restricted the format.
Bryan: I think we should avoid talking about things that we didn't
have in mind when we started this.
... We should really focus on the web browsing aspect.
Heiko: That is what I was talking about.
... maybe have something in the title about HTML.
Jo: I don't think we are restricted to that.
Heiko: How about adding "browsing" to the title?
Francois: We are going to end up with a really long title if we keep
adding things.
... Maybe we should discuss on the mailing list since it could take
a lot of time.
<francois> "Content Transformation Proxy Interoperability
Guidelines"
<francois> "Web Browsing Content Transformation Proxy
Interoperability Guidelines"
Heiko: Is this interoperability of CT proxies with each other?
Jo: I guess there is a hint of that in this title.
Francois: Let's think about this this week and I'll make some
proposals in the "title" thread.
LC-2067: conformance to SHOULD
Francois: About being clear about what conformance to normative
statements means.
... Our conformance statement is not clear in whether a conforming
implementation must follow the just the MUSTs or the MUSTs and the
SHOULDs
... The SHOULDs are there to recognize that there are some
situations where it would be hard to follow all of the guidelines.
... There should be a statement from the deployer why a SHOULD is
not followed.
... There was some concern on the mailing list that a deployment
could get around the guidelines by not following any of the SHOULDs
<hgerlach> [12]http://www.ietf.org/rfc/rfc2119.txt
[12] http://www.ietf.org/rfc/rfc2119.txt
Francois: We could do some sort of conformance statement that
deployers could fill out and sign.
<Bryan> +1
Francois: We need to clarify that we expect a conforming proxy to
follow the SHOULDs.
... We want to emphasize that it is a good idea to follow the
SHOULDs by creating a conformance statement.
Bryan: It is good idea to have a statement of compliance for
normative statements.
Francois: We want it to be clear that we want CT proxies to follow
all of the guidelines.
Jo: I agree with this. I think that Bryan's idea of using a tabular
format for the conformance statement is also a good idea.
<francois> PROPOSED RESOLUTION: re. LC-2067, state that conformance
applies to SHOULD statements as well. A justification is required
for not following SHOULD statements. Prepare an Implementation
Conformance Statement to be filled out by Transformation Deployments
willing to claim conformance to the spec.
Jo: I also think that we want to make it understood that the SHOULDs
be followed.
<jo> PROPOSED RESOLUTION: re. LC-2067, state that conformance
applies to SHOULD statements as well. A justification is required
for each circumstance in which a SHOULD statement is not followed.
Prepare an Implementation Conformance Statement to be filled out by
Transformation Deployments willing to claim conformance to the spec.
<francois> +1
<hgerlach> +1
<andrews> +1
<jo> +1
<Bryan> +1
RESOLUTION: re. LC-2067, state that conformance applies to SHOULD
statements as well. A justification is required for each
circumstance in which a SHOULD statement is not followed. Prepare an
Implementation Conformance Statement to be filled out by
Transformation Deployments willing to claim conformance to the spec.
<francois> ACTION: daoust to prepare an Implementation Conformance
Statement [recorded in
[13]http://www.w3.org/2008/09/16-bpwg-minutes.html#action01]
<trackbot> Created ACTION-846 - Prepare an Implementation
Conformance Statement [on François Daoust - due 2008-09-23].
Francois: I will work on a conformance statement. It would be nice
if we could extract this from the guidelines automatically.
LC-2050: restructuring, recoding and optimizing
LC-2050: restructuring, recoding and optimizing
<francois> [14]Sean's comments
[14]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0010.html
Francois: As I understand it, we don't use the terms that much.
<andrews> +q
Sean: Not sure what to do about the terms even though we don't use
them that much.
Francois: Maybe we should wait a while and see what happens with the
rest of the document.
Andrew: I think we should leave this as it is.
Jo: I think the definitions are useful. However, I don't think we
should have "dangling" definitions.
Bryan: If you create definitions, you should use them.
Jo: I am narrowly in favor of removing the definitions.
Andrew: How about mentioning that we are not going to use recoding
and optimization in the document?
Jo: That seems like a reasonable idea
<jo> PROPOSED RESOLUTION: Re LC-2050 move definitions to scope to
clarify that we are talking only about restructuring
<francois> +1
<hgerlach> +1
<andrews> +1
<Bryan> +1
+1
RESOLUTION: Re LC-2050 move definitions to scope to clarify that we
are talking only about restructuring
<jo> PROPOSED RESOLUTION: rec LC-2050 we don't intend to define
these concepts formally
+1
<jo> PROPOSED RESOLUTION: re LC-2050 we don't intend to define these
concepts any more formally than we do now
<andrews> +1
<francois> +1
+1
RESOLUTION: re LC-2050 we don't intend to define these concepts any
more formally than we do now
Summary of Action Items
[NEW] ACTION: daoust to prepare an Implementation Conformance
Statement [recorded in
[15]http://www.w3.org/2008/09/16-bpwg-minutes.html#action01]
[End of minutes]
Received on Tuesday, 16 September 2008 16:07:45 UTC