W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > September 2008

[minutes] CT Call Tuesday 16 September 2008

From: Francois Daoust <fd@w3.org>
Date: Tue, 16 Sep 2008 18:07:09 +0200
Message-ID: <48CFD9AD.8020608@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 16 September 2008 16:07:45 GMT