See also: IRC log
francois: Welcome Eduardo
Casais
... already known to us from a host of useful comments on the
mailing-list
[round of introductions]
Eduardo: I work for a small mobile content developer in Switzerland, previously worked for Nokia where I was involved in many things including UA-Prof
<francois> New draft of CT
jo: I could talk at length on this!
<francois> Jo's changelog and discussion
jo: I hope it includes all the
resolutions so far
... Hope to gather together anything missing (eg rewriting
HTTPS links holes) in the next 2-3 days
... considerable polish is required but would be a waste of
time until the substance is stable, which may take another
draft
... it will be useful if everyone gives this draft a deep
review
... santiy-check and make sure it says what we agreed
... check for consistency
... tighten the nuts and bolts (eg any shoulds that could be
musts?)
... and check if clarity can be improved
francois: everyone should send
comments to the mailing-list
... just like Eduardo has been doing
francois: introduced by Rob on the mailing-list.
rob: Yes. Don't think there is anything to do, but comes from a long discussion, so I wanted to check whether there was a reason not to include a Content-Location header in the response passed downstream to the phone
jo: do we need to propose text around this?
francois: Rob's said he doesn't think there is anything to propose here
Eduardo: RFC says the value of Content-Location also defines the base URI of the entity
francois: that's also one of my
fears
... and <link> is more correct
rob: I just wanted to see if
anyone has a need for this at all
... and so far I've heard no reason to want it
francois: could be a way to pass the canonical URI to the client for bookmarking
rob: I tried that on a real phone and it doesn't work
francois: correct, no-one uses that right now
<jo> PROPOSED RESOLUTION: No need to mention Content-Location header
francois: does anyone want us to go to TAG to check?
<francois> +1
<tomhume> +1
+1
RESOLUTION: No need to mention Content-Location header
francois: no overlap at the
moment between OMA doc and our doc
... OMA doc is an interface for a server, not for a proxy
... so there is no incompatibility and no overlap
... but there is some media-transcoding vocab defined that
could be useful in future work
jo: can we resolve LC-2051 now then?
<jo> PROPOSED RESOLUTION: ref LC-2051 This is out of scope for our document but may have interest for a general transformation vocab
+1
<tomhume> +1
<francois> +1
<SeanP> +1
<jo> +1
RESOLUTION: ref LC-2051 This is out of scope for our document but may have interest for a general transformation vocab
<francois> Close ACTION-868
<trackbot> ACTION-868 Review OMA STI to see if there's something relevant for CT for LC-2051 closed
francois: reminder to everyone to propose responses back to contributors ASAP
<francois> LC-2053
francois: postponed LC-2053
response recently
... about classes of device
... and section 4.1.5 of the old draft
<francois> LC-2053
<francois> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2053
jo: Eduardo can you please clarify what you want from LC-2053
<jo> ACTION: casais to review LC-2053 and clarify to group [recorded in http://www.w3.org/2008/11/11-bpwg-minutes.html#action01]
<trackbot> Created ACTION-880 - Review LC-2053 and clarify to group [on Eduardo Casais - due 2008-11-18].
francois: again triggered by one
of Eduardo's comments
... current wording is unclear about if a CT-proxy must
roll-back encoding changes made in responses when a form is
submitted
jo: which exceptions are we talking about?
francois: section 4.1.5
<francois> Alteration of HTTP Header Values
francois: the previous draft talked about Content-Encoding changes in the body, this has been removed
jo: we previously talked about
transforming request bodies but decided we didn't add much (if
anything) to the requirements that already exist
... do we have anything to say on something happening today
that we want to stop happening?
Eduardo: the mowser transcoder
doesn't handle Character-Encoding properly
... eg UTF-8 characters end up as Latin-1
jo: mowser hasn't been updated for a while and has lots of bugs, this is a known bug
Eduardo: Vodafone ES and PT transcoders don't handle numerical entities well
jo: but these are clear bugs, not
debatable ambiguities
... so avoiding carelessness or error is not part of our
specification
francois: we talked about adding
Encoding to the appendix E list
... as merely a list of heuristics
<jo> PROPOSED RESOLUTION: On the subject of character encoding, we have revisited it and we still can't think of anything useful other than "avoid bugs" when transforming between character encoding so we have decided to leave it
francois: was written as "recoded or restructured"
jo: I remember something about
this but could not find a resolution to follow when writing the
latest draft
... so here is one:
... I don't think we need to talk about transforming the
encoding of a request body
<jo> PROPOSED RESOLUTION: On the subject of character encoding, we have revisited it and we still can't think of anything useful other than "avoid bugs" when transforming between character encoding and to note that this is an example of a heuristic that the proxy may take into account when transforming content if it thinks that the encoding provided may mis-operate when presented on the client
francois: the only case is when the encoding of the response has been changed and the client is then submitting a form from that response
Eduardo: this isn't a heuristic, it's a rule
rob: yes, the rule is if you change Character-Encoding in one direction (server-to-phone) you have to change it in the other direction (phone-to-server) as well
Jo: we're not in the business of
specifying how to transform images, HTML etc, so we don't need
to specify this either
... this is not our job to write a "building transcoders for
dummies" book
francois: I second that point, we don't need to expand on that in the Guidelines
jo: do we want to add this to 4.2.8.1? Because it's not a heuristic
<jo> PROPOSED RESOLUTION: On the subject of character encoding, we have revisited it and we still can't think of anything useful other than "avoid bugs" when transforming between character encoding (which we don't intend to say) and add it to the list in 4.2.8.1 so that character encoding is specifically referred to
+1
<francois> +1
<SeanP> +1
<tomhume> +1
<jo> PROPOSED RESOLUTION: On the subject of character encoding, we have revisited it and we still can't think of anything useful other than "avoid bugs" when transforming between character encoding (which we don't intend to say) but add it to the list in 4.2.8.1 so that character encoding is specifically referred to
RESOLUTION: On the subject of character encoding, we have revisited it and we still can't think of anything useful other than "avoid bugs" when transforming between character encoding (which we don't intend to say) but add it to the list in 4.2.8.1 so that character encoding is specifically referred to
<jo> ACTION: jo to enact resolution on 4.2.8.1 ref adding character-encoding to the list of format, layout, dimensions etc. [recorded in http://www.w3.org/2008/11/11-bpwg-minutes.html#action02]
<trackbot> Created ACTION-881 - Enact resolution on 4.2.8.1 ref adding character-encoding to the list of format, layout, dimensions etc. [on Jo Rabin - due 2008-11-18].
Eduardo: do we need to point out the requirements of what the server expects?
<jo> PROPOSED RESOLUTION: do not discuss alteration of request body in respect of character encoding
francois: do we need to mention that altering the request-body isn't envisaged except "rolling back" changes like Character-Encoding?
<francois> +1
<SeanP> +1
<tomhume> +1
rob: there are a few other changes that need rolling back too - for example pasting back together inputs that got split amongst sub-pages
+1
RESOLUTION: do not discuss alteration of request body in respect of character encoding