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

[minutes] CT Call Tuesday 4 November 2008

From: Francois Daoust <fd@w3.org>
Date: Tue, 04 Nov 2008 18:21:41 +0100
Message-ID: <491084A5.1000007@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/11/04-bpwg-minutes.html

... and copied as text below.

We took a few resolutions on the remaining Last Call comments:
- ref LC-2038, resolve partial. Answer "no, these are not best 
practices, but guidelines". Don't change the text.
- ref LC-2049 resolve no, URI patterns can never be more than a 
heuristic, but we will move the list of examples to a non normative appendix
- ref LC-2072, resolve yes, and insert a termref to restructured and an 
Xref to 4.1.5.3
- ref LC-2073, resolve no, we are not aware of any satisfactory 
heuristics, but understand that CT Proxy vendors will need to adopt 
heuristics of some kind so we have no choice but to leave it open

Reminder: please prepare the draft responses on comments for which we 
resolved no. Thanks!
See:
  http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Oct/0051.html


Francois.



04 Nov 2008

    [2]Agenda

       [2] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Oct/0066.html

    See also: [3]IRC log

       [3] http://www.w3.org/2008/11/04-bpwg-irc

Attendees

    Present
           Francois, tomhume, SeanP, jo, rob, Bryan(IRC)

    Regrets
           AndrewS

    Chair
           francois

    Scribe
           Jo

Contents

      * [4]Topics
          1. [5]Where we are
          2. [6]LC-2038 - is it a list of Best Practices? Be explicit it
             that's the case
          3. [7]LC-2049 - forbid the alteration of the request when the
             URI follows some mobile pattern (*.mobi, wap.*, ...)
          4. [8]LC-2053 - Classes of devices
          5. [9]LC-2072 - what is a restructured desktop experience?
          6. [10]LC-2073 - heuristics and web sites
          7. [11]LC-2040 - X-Device-* should be in an Internet Draft
          8. [12]Next week's call
          9. [13]Discussions on WMLProgramming
      * [14]Summary of Action Items
      _________________________________________________________

Where we are

    fd: we spent a whole day on CT during the F2F which was really
    useful

    <francois> [15]F2F day 1 on CT

      [15] http://www.w3.org/2008/10/20-bpwg-minutes.html

    fd: took quite a few resolutions. Any questions on that?
    ... addressing the LC comments showed that there was some kind of
    misunderstanding between what people think the spec is about and
    what it actually is about, so we need to focus more on what be
    enforced or made normative
    ... if we can end up with a small text then we will have done our
    job
    ... OK?

    jo: well some of the non normative things add value, but in general
    "I don't disagree (TM)"

    seanp: I thought that we were going to have normative and
    informative parts, rather than trying to reduce it to just being
    normative

    fd: yes, well that's basically what I mean, but we shouldn't mix
    normative and informative parts
    ... we should be as clear as possible
    ... by having a clean structure
    ... next step is for Jo to slave away night and day to update the
    document
    ... need to look at comments where we resolved "no" as the others
    will basically be a reference to the updated draft
    ... I sent something out on this assigning people to comments to
    draft the responses

    seanp: should we update in tracker or send to the list

    fd: update the tracker, if you are OK with that

    <Zakim> jo, you wanted to ask if Tom has access to LC Tracker?

    fd: then update the mailing list when you have done that

    <francois> [16]Last Call tracker

      [16] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/

    <tomhume> "yes!"

    <Bryan> Hi, FYI I am here but chat-only today

    fd: technically this is easier but must not forget working in public
    ... some comments on 4.1.5 were not actually talking about the
    things we agreed on, and so I've listed the remaining LC comments as
    the agenda for today

LC-2038 - is it a list of Best Practices? Be explicit it that's the
case

    <francois> [17]LC-2038

      [17] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2038

    jo: no this is not recommended, it's all MAY

    seanp: I don't think we need to change anything, it says what we
    mean, we don't claim this to be best practice?

    <francois> PROPOSED RESOLUTION: ref LC-2038, resolve partial. Answer
    "no, these are not best practices, but guidelines"

    <francois> PROPOSED RESOLUTION: ref LC-2038, resolve partial. Answer
    "no, these are not best practices, but guidelines". Don't change the
    text.

    <SeanP> +1

    <tomhume> +1

    <rob> +1

    <francois> +1

    RESOLUTION: ref LC-2038, resolve partial. Answer "no, these are not
    best practices, but guidelines". Don't change the text.

LC-2049 - forbid the alteration of the request when the URI follows
some mobile pattern (*.mobi, wap.*, ...)

    <francois> [18]LC-2049

      [18] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2049

    PROPOSED RESOLUTION: ref LC-2049 resolve no, URI patterns can never
    be more than a heuristic

    <SeanP> +1

    PROPOSED RESOLUTION: ref LC-2049 resolve no, URI patterns can never
    be more than a heuristic, but we will move the list of examples to a
    non normative appendix

    <rob> +1

    rob: as jo just says, you may get moved around between URIs so it's
    not so much what you do with the request it's more what you do with
    the response

    <francois> +1

    <SeanP> +1

    <tomhume> +1

    rob: less to do with what you do with the UA on the request path

    RESOLUTION: ref LC-2049 resolve no, URI patterns can never be more
    than a heuristic, but we will move the list of examples to a non
    normative appendix

LC-2053 - Classes of devices

    fd: notes that the contributor of these comments has been invited to
    join the group as an invited expert, because of the value of his
    contributions, and he has now agreed but the process of his joining
    has not yet completed

    <francois> [19]LC-2053

      [19] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2053

    <dom> [his invitation is at the last step, now, fwiw]

    <Zakim> jo, you wanted to suggest that for the same reason as the
    previous one, the intention of content can't be unambiguously
    inferred from a URI

    jo: suggest that we don't fully understand this and wait for Eduardo
    to be on a call so we can ask what he means

LC-2072 - what is a restructured desktop experience?

    <francois> [20]LC-2072

      [20] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2072

    fd: what is a restructured desktop experience?

    jo: well we don't mean that it's a desktop that has a chain saw
    taken to it

    seanp: I think the problem is that we define this after where this
    reference is

    PROPOSED RESOLUTION: ref LC-2072, resolve yes, and insert a termref
    to restructured and an Xref to 4.1.5.3

    <francois> +1

    <SeanP> +1

    RESOLUTION: ref LC-2072, resolve yes, and insert a termref to
    restructured and an Xref to 4.1.5.3

LC-2073 - heuristics and web sites

    <francois> [21]LC-2073

      [21] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2073

    fd: MNott is asking us to provide the undefined heuristics which we
    don't want to do

    PROPOSED RESOLUTION: Ref LC-2072, resolve no, we are not aware of
    any recommended heuristics, but understand that CT Proxy vendors
    will need to adopt heuristics of some kind so we have no choice but
    to leave it open

    PROPOSED RESOLUTION: Ref LC-2072, resolve no, we are not aware of
    any satisfactory heuristics, but understand that CT Proxy vendors
    will need to adopt heuristics of some kind so we have no choice but
    to leave it open

    +1

    <tomhume> +1

    <francois> +1

    <SeanP> +1

    RESOLUTION: Ref LC-2073, resolve no, we are not aware of any
    satisfactory heuristics, but understand that CT Proxy vendors will
    need to adopt heuristics of some kind so we have no choice but to
    leave it open

LC-2040 - X-Device-* should be in an Internet Draft

    <francois> [22]LC-2040

      [22] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2040

    jo: I think it's right to say that if we say MUST then maybe its
    right to say we are changing the protocol, so if we say SHOULD
    instead then that would be OK, given that our conformance statement
    requirements are that you have to say why you don't conform to a
    SHOULD if you dont

    francois: echoes what jo just said

    seanp: I thought we already checked with the IETF and they said it
    would take a long time and it wasn't really worth doing

    fd: that was about extensions to Cache-Control
    ... this is a bit different in that we are allowed to add headers
    with X- but putting a MUST here is defining an extension of the
    protocol
    ... but equally I think that if we take the MUST out then we will be
    criticised by the other side

    <scribe> ACTION: daoust to ask [someone] about adding IETF headers
    [recorded in
    [23]http://www.w3.org/2008/11/04-bpwg-minutes.html#action01]

    <trackbot> Created ACTION-879 - Ask [someone] about adding IETF
    headers [on François Daoust - due 2008-11-11].

    jo: doesn't have to be in a standard to be best practice

    fd: er, humm, doh, er

    <SeanP> It's a "de facto" guideline

    fd: there is one other pending best practice, plus we can postpone
    discussion of issues raised by eduardo, till he joins the group

Next week's call

    [discussion of Remembrance day celebrations]

    [call will go ahead]

Discussions on WMLProgramming

    tom: a) legal advice, dealt with

    <francois> [24]Tom's collection of comments

      [24] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0000.html

    tom: b) ROBOTS.TXT like thing, seems to be dealt with by POWDER but
    Eduardo had comments on that
    ... c) the Via header, requiring the presence of the URI
    ... d) SOAP etc. dealt with under 4.13
    ... e) non-ability of people to alter headers
    ... mark content as Mobile using DOCTYPE
    ... not exactly fool proof

    fd: is there anything we should reconsider

    tom: would be good to understand more about POWDER

    jo: didn't we say that you can use META HTTP-EQUIV cache-control:
    no-transform

    fd: well yes we did

    seanp: there was a resolution that the HTTP equiv should be
    consulted if the relevant HTTP header not present

    fd: so back to POWDER
    ... it's a "bit of a semantic thing" which could eventually replace
    the good ole ROBOTS
    ... in the past we thought that it could be used by Content
    Providers to advertise their position on CT
    ... but POWDER doesn't exist yet and also we'd need to define a
    vocabulary and that would be hard, take a lot of time and be out of
    scope
    ... but we have put it in the Scope for Future Work appendix
    ... and it would be "cool", also could be a way of CT proxies
    advertising their capabilities to Content Providers

    tom: so our position is that it's not feasible now, but will be
    feasible in the future once POWDER is defined and we have a vocab

    fd: yes, that's basically it, a vocabulary needs to be defined
    though
    ... seems like a Well Known Location is not considered good practice

    tom: can we kick off work on a vocab?

    fd: the semantics can be worked on independently of the syntax of
    POWDER being agreed
    ... so someone somewhere can start work on this
    ... but it is not all that easy to define just a simple vocab e.g.
    the DDR Core Vocab

    [adjourned]

Summary of Action Items

    [NEW] ACTION: daoust to ask [someone] about adding IETF headers
    [recorded in
    [25]http://www.w3.org/2008/11/04-bpwg-minutes.html#action01]

    [End of minutes]
Received on Tuesday, 4 November 2008 17:22:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 4 November 2008 17:22:19 GMT