See also: IRC log
<trackbot> Date: 16 September 2008
<francois> Agenda: 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.
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.
<francois> Sean's proposals
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.
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> 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 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
<francois> Sean's comments
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