See also: IRC log
<scribe> scribenick: jar
norm: Next meeting 8 Jan, I assume - will scribe then
skw: Raman is on holiday for about a month. Not expected today.
<DanC> +1 approve http://www.w3.org/2001/tag/2008/12/04-minutes
skw: Propose to approve minutes --
... Meet on the 8th.
<DanC> +1 meet again 8 Jan
RESOLUTION: Approve http://www.w3.org/2001/tag/2008/12/04-minutes
danc: Take a look at this page = "URI Syntax Tinkering"
... (reads through the page)
Idea (HTML5): patch 3986 by adding characters to the unreserved production...
danc: idea: Derive a parser from the URI spec, implement weird processing before, demonstrate equivalence. [see tinkering document]
... "Try it"
danc: "Try it" section is step 1 out of 5 steps.
... Spaces before and after, I believe, work.
<DanC> add this
<DanC> / %00-%20
<DanC> to get
<DanC> unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" / %00-%20
jar: doesn't work in FF 3.0.3, for me at least
danc: (finishing up review of the tinkering document) Step 1 done. Have gotten partway into step 2.
<DanC> action-188 due 8 Jan 2009
<trackbot> ACTION-188 Investigate the URL/IRI/Larry Masinter possible resolution of the URL/HTML5 issue. due date now 8 Jan 2009
noah: Where are we going with this?
danc: Success is a different layering of the specs.
... The current HTML5 spec says you should create a modified version of the URI spec.
... The alternative is to munge the input in a certain way, then use the URI spec as written.
noah: Looks to me like they're redefining the letters "URI"
danc: No, they're redefining the letters "URL"
noah: So you're not proposing to change "URL" to something else - to let that acronym stand in HTML5?
<DanC> " - uri to ietf (maybe danc as editor?)"
danc: yes, thinking about such a change
skw: Wanted to give TAG a chance to discuss whether changes proposed by Tim are changes the TAG would like the finding editor to make.
noah: How about if I just do the "obvious thing"?
<trackbot> ACTION-209 -- Noah Mendelsohn to attempt to address critical concerns from end of 11 Dec self-describing web discussion -- due 2009-01-15 -- OPEN
<trackbot> ACTION-207 -- Jonathan Rees to try to wordsmith to get rid of 'Semantic Web' and submit for review -- due 2008-12-18 -- OPEN
noah: There were a few actions assigned to others, e.g. some to Jonathan
<DanC> (there's one other action on noah; there are no others re self-describing web)
jar: (ouch ... that action was due today)
noah: I want to go straight to something that should be able to command consensus
action-207 due 6 jan 2009
<trackbot> ACTION-207 Try to wordsmith to get rid of 'Semantic Web' and submit for review due date now 6 jan 2009
noah: To minimize thrashing, let's try to finish up this document ASAP.
skw: When will TAG election results be available?
<DanC> action-165 due 8 Jan 2009
<trackbot> ACTION-165 Formulate erratum text on versioning for the web architecture document due date now 8 Jan 2009
(discussion tabled awaiting actions)
noah: Has this action been discharged / stalled?
<skw> "DO: I think NM has made some progress, I request to be released from this, too much load elsewhere" [Stuart Williams]
DO: We were to say approximately "Dear EXI WG, we look forward to your answer to the notes the TAG sent you previously."
skw: Has anyone else noticed or read the evaluation report http://www.w3.org/TR/2008/WD-exi-evaluation-20080728/ ? Has it influenced your opinions?
<DanC> (I don't need Noah to run this by the TAG; I'm happy for him to send it on my/our behalf)
noah: They want to just move ahead, want to know TAG's blocking concerns.
... I will draft something, and send it to DO cc the list.
DO: I hope the TAG going forward will stand by the feedback it gave a couple years ago.
noah: Speed story fuzzy, compactness is good; intuitively the speed story won't be bad.
DO: is it worth having two XML serializations?
<Zakim> skw, you wanted to ask about the EXI evaluation report at: http://www.w3.org/TR/2008/WD-exi-evaluation-20080728/
noah: I remain nervous about it. 5 years ago was too early to do binary XML. By now I hope the XML community has a better idea of good practice and will be able to handle EXI. [scribe's liberty]
skw: We had said that the measurement report (circa July 2006) was hard to digest; the newer evaluation report presents the results in more compact and clearer manner.
... [Measurement Report: http://www.w3.org/TR/2006/WD-exi-measurements-20060718/]
... [Evaluation Report: http://www.w3.org/TR/2008/WD-exi-evaluation-20080728/]
noah: I thought they said the work was finished w.r.t. size but not speed, and that a speed report was forthcoming
DO: Tim wanted a space/speed scatterplot
<DanC> ACTION-176 due 8 Jan 2009
<trackbot> ACTION-176 draft comments on EXI w.r.t. evaluation and efficiency due date now 8 Jan 2009
noah: Will try to get to this in the next few days
<trackbot> ACTION-176 -- Noah Mendelsohn to send comments on EXI w.r.t. evaluation and efficiency -- due 2009-01-08 -- OPEN
skw: Has anyone had time to review this?
danc: When ready, we should post [pointer to minutes] to public-tag-announce. Also AB would like to hear our periodic report.
... How about we approve minutes contingent on 1-2 particular people OK'ing them?
<DanC> I did publish the photo in http://www.w3.org/2001/tag/2008/12/09-f2f-agenda
<DanC> (somebody resized it; nifty)
<DanC> ok, so critical path is noah, norm, dan
norm: (volunteers to read f2f minutes)
jar: will do outstanding small edits today
danc: public-tag-announce is for minutes
<DanC> "public-tag-announce (archive, RSS feed) is used for announcements from the TAG of minutes, ... " -- http://www.w3.org/2001/tag/
noah: Third day is IRC logs run through the script - not missing anything?
danc: Common sense would say yes.
(investigation concluding that Henry's 3rd day minutes are under w3.org/tag/2001/...)
RESOLUTION: Dec F2F minutes approved contingent on approval from Noah, Norm, and Dan
danc: Ian gave an update to incoming HTML5 cochair Sam Ruby.
<DanC> <Hixie> MikeSmith: so i met with lisa
<DanC> <Hixie> MikeSmith: she's open to us splitting off the protocol
<DanC> part of websocket, the content-sniffing section, the uri
<DanC> section, and a brief definition of the Origin header, and
<DanC> submitting them as four tentative IDs
<DanC> <Hixie> (the api part of web socket would go into a separate w3c draft)
<DanC> <Hixie> MikeSmith: assuming there's no objections, i'll start
<DanC> looking at doing that in early january
<DanC> "Applications Area (app)
<DanC> Lisa Dusseault, Open Source Applications Foundation "
danc: Lisa is an IESG member.
... Lisa had raised concerns about websockets. Good that she's talking directly with Ian H.
<DanC> most likely time is Tue 6 Jan 16:00 BOS
danc: An IETF/W3C liaison meeting is coming up...
skw: What's content sniffing discussion about - what does it have to do with IETF?
danc: It impinges on HTTP.
... No chance of changing legacy software, so best solution is to document what is actually deployed.
noah: What are chances of being able to tell the "conservative in what you send / liberal in what you consume" story?
danc: Barth did a very cool data collection exercise
... he also might be editing the Origin: spec
<DanC> ^ adam barth's work
<DanC> (you're welcome to tell the meeting and hope it gets to the relevant places, but if you're asking me to convey this, Noah, I'm saying "no, can't add that to my list, but you're welcome to attend the IETF/W3C liaison telcon")
noah: Content-type counts. (full stop) If you're receiving, the story is longer.
jar: (I interpret Noah as saying: To be a compliant sender, you have to mean Content-type. But a defensive receiver will have to be more generous, since so many senders are not compliant.)
<noah> What I tried to say was: calling the call "sniffing" suggests a focus on receivers only; I think that if anything is to be said, it needs to tell a story about when it is or isn't OK to send anything other than text as Content-type: text/plain, and when it is or isn't ok as a receiver to infer the presence of anything other than text from Content-type: text/plain. Sniffing sounds like a spec...
<noah> for receivers only.
danc: The worst nightmare in standardization: What happens when an emergency [phone] call is processed.
... W3C is working on geolocation, so your cell phone can transmit location to web apps.
danc: But you can't do this without a privacy infrastructure.
<DanC> "IETF RAI and APP concerns about location privacy "
danc: Concerns about phone/location privacy are on the upcoming teleconference.
[cf. IETF geopriv http://tools.ietf.org/wg/geopriv/]
skw: Merry Christmas to all.