Re: [minutes] CT Call Tuesday 11 November 2008

LC-2023
 > [ Note that we had indeed resolved something similar to the end of the
 > first resolution on 30 September 2008:
 > - On character encoding mention this under 4.3.6.1 and respond "Yes
 > partial" to LC-2023
 >  http://www.w3.org/2008/09/30-bpwg-minutes.html#item05 ]
 >
 >
OK I was about to beat myself up for sloppy editing, so I checked what I 
thought I had done with that resolution and this is what I noted:

"
      RESOLUTION: On character encoding mention this under 4.3.6.1 and
      respond "Yes partial" to LC-2023

Added as a note under what was 4.3.6.1
<p>Other than as noted in this section the nature of restructuring that
is carried out, any character encoding alterations and what is omitted
and what is inserted is, as discussed in <specref ref="sec-scope"/>, out
of scope of this document.</p>         "

So I did action it and I don't have to beat myself up for sloppy 
editing. However I will beat myself up for forgetting that I had taken 
editorial discretion and added that note. It could be that the note 
would be better at the top of the section ...

Can't seem to keep 100 odd resolutions in my head at the same time any 
more. Suffering from LCC-itis.

Jo



On 11/11/2008 17:14, Francois Daoust wrote:
> 
> Hi,
> 
> The minutes of today's call are available at:
>  http://www.w3.org/2008/11/11-bpwg-minutes.html
> 
> ... and pasted as text below.
> 
> No call next week, meaning next call is on 25 November 2008.
> Please use the list to send comments on the new draft for discussion. 
> I'll try to gather those that need to be actioned afterwards.
> 
> 
> Resolutions taken during the call
> -----
> On the Content-Location header:
> - No need to mention Content-Location header
> 
> On OMA STI:
> - ref LC-2051 This is out of scope for our document but may have 
> interest for a general transformation vocab
> 
> On Character encoding:
> - 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
> - do not discuss alteration of request body in respect of character 
> encoding
> 
> [ Note that we had indeed resolved something similar to the end of the 
> first resolution on 30 September 2008:
> - On character encoding mention this under 4.3.6.1 and respond "Yes 
> partial" to LC-2023
>  http://www.w3.org/2008/09/30-bpwg-minutes.html#item05 ]
> 
> 
> Francois.
> 
> 
> 11 Nov 2008
> 
>    [2]Agenda
> 
>       [2] 
> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0018.html
> 
>    See also: [3]IRC log
> 
>       [3] http://www.w3.org/2008/11/11-bpwg-irc
> 
> Attendees
> 
>    Present
>           francois, tomhume, rob, SeanP, Eduardo, jo
> 
>    Regrets
>    Chair
>           francois
> 
>    Scribe
>           rob
> 
> Contents
> 
>      * [4]Topics
>          1. [5]Welcome to Eduardo Casais
>          2. [6]New Draft
>          3. [7]Content-Location
>          4. [8]OMA Standard Transcoding Interface
>          5. [9]Draft responses to "resolved no" comments
>          6. [10]LC-2053 - classes of devices
>          7. [11]Unclear form encoding must be preserved for the server
>      * [12]Summary of Action Items
>      _________________________________________________________
> 
> Welcome to Eduardo Casais
> 
>    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> [13]New draft of CT
> 
>      [13] 
> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/081107 
> 
> 
> New Draft
> 
>    jo: I could talk at length on this!
> 
>    <francois> [14]Jo's changelog and discussion
> 
>      [14] 
> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0017.html
> 
>    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
> 
> Content-Location
> 
>    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
> 
> OMA Standard Transcoding Interface
> 
>    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
> 
> Draft responses to "resolved no" comments
> 
>    francois: reminder to everyone to propose responses back to
>    contributors ASAP
> 
> LC-2053 - classes of devices
> 
>    <francois> [15]LC-2053
> 
>      [15] 
> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2053 
> 
> 
>    francois: postponed LC-2053 response recently
>    ... about classes of device
>    ... and section 4.1.5 of the old draft
> 
>    <francois> [16]LC-2053
> 
>      [16] 
> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2053 
> 
> 
>    <francois>
>    [17]http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidel
>    ines-20080801/2053
> 
>      [17] 
> 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 [18]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].
> 
> Unclear form encoding must be preserved for the server
> 
>    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> [19]Alteration of HTTP Header Values
> 
>      [19] 
> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/081107#sec-altering-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
>    [20]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
> 
> Summary of Action Items
> 
>    [NEW] ACTION: casais to review LC-2053 and clarify to group
>    [recorded in
>    [21]http://www.w3.org/2008/11/11-bpwg-minutes.html#action01]
>    [NEW] ACTION: jo to enact resolution on 4.2.8.1 ref adding
>    character-encoding to the list of format, layout, dimensions etc.
>    [recorded in
>    [22]http://www.w3.org/2008/11/11-bpwg-minutes.html#action02]
> 
>    [End of minutes]
>

Received on Tuesday, 11 November 2008 18:09:25 UTC