See also: IRC log
fd: we spent a whole day on CT during the F2F which was really useful
<francois> F2F day 1 on CT
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> Last Call tracker
<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
<francois> LC-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.
<francois> LC-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
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> LC-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
<francois> LC-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
<francois> LC-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
<francois> LC-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 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
[discussion of Remembrance day celebrations]
[call will go ahead]
tom: a) legal advice, dealt with
<francois> Tom's collection of comments
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]