See also: IRC log
<scribe> scribe: Jonathan Rees
<scribe> scribenick: jar
Minutes of 23-25 Sept F2F - table approval until next time
(discussion of 2 week minutes submission rule)
Resolved: approve minutes of 1 October 2009 ( http://www.w3.org/2001/tag/2009/10/01-minutes )
John K will read minutes of Oct 8; we'll take up approval next time
who will be at TPAC?
ashok, raman, noah, henry,
<DanC> I plan to be at TPAC
Noah has worked out meeting time with HTML WG
(well, the exact time depends)
danc: What shall we talk about?
noah: Thanks to those who responded to the issue summary request
<DanC> (re shepherd... here I was thinking I wasn't shepherding any issues, but when I checked, I found the site-data thing was in my court)
noah: Reminder about call for exclusions; period ends today.
... What HTML-related things might we want to discuss at TPAC?
... (re session planning)
danc: How about a poll.
<raman> level of enthusiasm on call is depressing
jar: Won't be at TPAC, no particular desires around TAG/TPAC discussions.
raman: Individual [one on one, not large group] discussions will be the important thing
ashok: I would like to ask whether there has been any progress since last meeting - is anyone listening to the TAG?
... authoring guidelines, extensibility, URIs, ...
... not that there hasn't been any; just would like to track progress ...
danc: Could you (Ashok) go over last time's notes?
noah: Ian did prepare an authoring draft and wants us to review it
<DanC> (I spent some time looking at the authoring draft, as did masinter)
noah: (continuing poll) I would like to go over our minutes in prep for TPAC
<noah> ACTION-319 on Noah: Consider HTML media type issue for TPAC agenda(s) Due: 2009-10-29
<noah> I was supposed to get input from Larry as input to my ACTION 319 on media types. Was hoping Larry would be here today to clarify status.
ht: we could get some benefit from discussing RDFa.
noah: consider the HTML media type issue
ht: yes, remember Tim's desire to have XHTML handled properly when served as text/html
<noah> ACTION: Noah to respond to HTML WG chairs with suggested TPAC topics -- see minutes of 22 Oct [recorded in http://www.w3.org/2009/10/22-tagmem-irc]
<trackbot> Created ACTION-320 - Respond to HTML WG chairs with suggested TPAC topics -- see minutes of 22 Oct [on Noah Mendelsohn - due 2009-10-29].
danc: (continuing poll) about URIs, what is the time scale? sequencing of the two specs (IRI / HTML5)
johnk: RDFa / microdata is worth discussing. also distributed extensibility
noah: Call for agenda for TAG meeting at TPAC
<Zakim> DanC, you wanted to note progress on spec modularity
<trackbot> ACTION-318 -- Noah Mendelsohn to send note to Device APIs and Policy (DAP) Working Group on behalf of the TAG -- due 2009-10-15 -- OPEN
<noah> * From minutes of 8 Oct 2009: RESOLVED that that LMM edit 2009Sep/0073 lightly as discussed 8 Oct and Noah send to Device APIs and Policy Working Group on behalf of the TAG
<noah> * ACTION-318 Send note to Device APIs and Policy (DAP) Working Group on behalf of the TAG - on Noah Due: 15 Oct 2009
action-318 due october 25
<trackbot> ACTION-318 Send note to Device APIs and Policy (DAP) Working Group on behalf of the TAG due date now october 25
<DanC> (does it matter when we send our thingy to the DAP WG? ht? (picking on you somewhat arbitrarily))
ashok: There's a similar note on policy [...] to media annotations WG -- should we make a more general statement? [Scribe didn't get this, sorry]
danc: Not my style. The anybody/nobody/somebody problem
<noah> ACTION Noah to bug Larry about his input to ACTION-318
<trackbot> Created ACTION-321 - Bug Larry about his input to ACTION-318 [on Noah Mendelsohn - due 2009-10-29].
The following is what wants an answer: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0095.html [re server-side deployment]
<noah> NM: I'm not sure whether the link in the agenda http://lists.w3.org/Archives/Public/www-tag/2009Oct/0042.html [re confused deputy, Oct 19] is also pertinent [scribe: it is, but it's a different issue]
<noah> [quoting 0095 from Anne, re server-side deployment:]
<noah> On Wed, 24 Jun 2009 19:22:35 +0200, Henry S. Thompson <firstname.lastname@example.org>
<noah> > One point of clarification: my (admittedly imperfect) understanding
<noah> > was that the most important parts of CORS have to be implemented
<noah> > _server_-side for the proposal to achieve its goals. If that's true,
<noah> > browser deployment alone is insufficient. Is that a misunderstanding
<noah> > on my part?
<noah> As was pointed out elsewhere in this thread it was.
<noah> I was wondering if the TAG considers this item closed or wishes to know
<noah> something more, in which case I'd like to hear about it! I'm trying to
<noah> wrap up email threads and this is one of them. Thanks!
<noah> Kind regards,
<noah> Anne van Kesteren
<DanC> ("this" = the confused deputy stuff or the server/client-side stuff?)
raman: I'm not a security expert, but have heard individuals I respect question it
<DanC> [Raman's "it" = ] (a) the confused deputy problem in 0042 or (b) the server/client-stuff in 0095? [scribe believes (a)]
noah: It's appropriate for the TAG to become a focal point.
ht: I'm looking to see the current state of the thread that my email kicked off. [scribe: the thread mixes Dan's (a) and (b)]
noah: Does CORS go to LC on its own, or with the other webapps documents?
jar: On its own, I believe
raman: If we have things to say, we should do so now, not wait for their LC.
<noah> Dan, I'm curious whether http://lists.w3.org/Archives/Public/www-tag/2009Oct/0042.html is about CORS at all. [scribe: it is]
danc: Regarding 0042 [confused deputy] - there is a distinction between "Anne and others" don't see a problem and "the WG" doesn't see a problem.
<ht> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0104.html [re core criticism about CORS / confused deputy]
danc: But confused deputy is not in their issues list ...
... If Mark Miller has a problem with this it needs to get onto their issues list
ht: The thread peters out into unresolved disagreement.
... we could say: It doesn't look like you're done, but I see that there is no open issue
... what is their process?
danc: I think Mark M has raised an issue, and I'm inclined to ask the chair to add it to their list
<DanC> (ask the chair because: their chair might clarify the way they handle issues)
noah: Propose ht to send a request on behalf of the TAG, that the WG open an issue [re confused deputy]
... alternative: ht to send a request (not directly on behalf of TAG) etc
<DanC> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0095.html [scribe: changing topic back to (b) = server-side deployment]
<noah> DC: I am [now] talking about the message of 8 Oct. [webapps 0095], not 19th [www-tag 0042]
danc: There are two parts of this agendum on today's meeting.
ht: Thought this _was_ about 19 October .
danc: Let's put aside confused deputy for now.
... It's OK with me to let 8 Oct (0095) drop.
ht: I'm not competent to judge this...
<raman> need to leave --- bye all!
<noah> NM: Seems to me that the need for interoperable server side implementations might be an important CR exit criterion.
(Discussion of CR exit critieria. Can criteria be added after LC?)
danc: Usually some of these decisions wait until discussion with the director.
<ht> [How about:] "Sorry for the delay -- the discussion has clarified the current relevance of client-side implementations, and as far as that goes the TAG is happy.
<ht> We do assume that demonstrating interoperable server-side implementation will be a necessary part of your CR exit criteria -- could you please confirm that?"
<noah> should that be s/could/would/ ?
(Agreement that HT should send that)
<noah> JAR: The original one that Henry sent on behalf of the TAG, http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1215.html, is on confused deputy.
<ht> [quoting from 1215] "the new functionality
<ht> > provided would, on the one hand, be insufficiently secure while, on
<ht> > the
<ht> > other, discouraging the provision of something more satisfactory.
ht: [speaking to why this discussion has gotten mixed up] There are two parts to the paragraph in (1215).
... Anne responded to the part about server side deployment, asking if that was still an issue for us...
... but that's not the deeper question posed at the end of the same message (1215), about how secure it will be.
The 2nd part of 1215 is the "even if it did" part, which gave rise to "unaddressed security concerns" thread (0104 see above)
ht: 0102 is from Mark Miller. He says: You never addressed confused deputy vulnerabilities; that's what matters.
... That thread has not been reflected as an issue, or been brought to a resolution
danc: And Anne is the editor, and says "I and others don't see an issue"...
noah: We agreed to say something right? So we're done?
... Henry will send a note to Art.
<DanC> URIs, deep linking, framing, adapting and related concerns Rotan Hanrahan (Friday, 16 October) http://lists.w3.org/Archives/Public/www-tag/2009Oct/0031.html
danc: Rotan H brought this to the TAG
noah: As you recall... TAG worked on "deep linking" way back when
<noah> TAG Finding on Deep Linking: http://www.w3.org/2001/tag/doc/deeplinking-20030911
noah: and now some sites are saying "don't link to me *at all*"
<noah> From the finding's conclusion:
<noah> Attempts at the public-policy level to limit the usage, transmission and publication of URIs at the policy level are inappropriate and based on a misunderstanding of the Web's architecture. Attempts to control access to the resources identified by URIs are entirely appropriate and well-supported by the Web technology.
<noah> JAR: I think people are looking for legal advice
<noah> NM: Finding is anappropriate?
<noah> JAR: No, but now we need a legal reading.
danc: But web architecture is also social, it's the whole thing.
danc: There's no other body that can take a stand here.
... (than the TAG)
noah: Maybe take deep linking finding and turn it inside out?
... linking generally, with deep linking as a special case.
<noah> I think that's covered in metadata in URI finding, no?
<noah> Still could fix this one.
<ht> Oh bother, /me is late -- bye!
danc: Problem, it says don't use security by obscurity. But long random numbers are used to good effect... so that needs revision
noah: So it seems we could do better.
<noah> Dan and I both seem intrigued about doing better, anyone else?
ashok: On a conversation about mobile devices, there was a question that a URI couldn't be made public for security reasons.
noah: URI for a device - such as a phone?
... Web server associated with it?
noah: URIs move through the network in the clear a lot, yes?
johnk: Often there's a proxy, which might not be talking http on the far side (to the device)
noah: Is this really the web, between proxy and the phone?
<DanC> (indeed, it's using web technologies, but it's not "The Web". or something... I've never found a good way to write this up... it's somewhat like http://my.yahoo.com/ too. and intranets.)
<Zakim> DanC, you wanted to note that our deep linking finding (and webarch) goes to far in saying "the long-random-number /capability URI pattern is bad"
johnk: Not sure that mobile phone URIs are relevant to this discussion...
<trackbot> ISSUE-25 -- What to say in defense of principle that deep linking is not an illegal act? -- CLOSED
jar: Will a revised finding serve the present need?
<Zakim> noah, you wanted to say, speaking for myself, I don't want to hang up on the legal issues
noah: What needs to be said: You should understand the value of network effects. That understanding needs to influence your legal decisions. This affects what the web will be like.
... If we can say something about legal precedent in addition, that's good too
<DanC> ACTION: DanC to ask W3C management for writing resources re hyperlinking [recorded in http://www.w3.org/2009/10/22-tagmem-irc]
<trackbot> Created ACTION-322 - Ask W3C management for writing resources re hyperlinking [on Dan Connolly - due 2009-10-29].
jar: When you're deciding whether to publish a URI, you're not going to ask what web architecture is, you're going to ask whether you're likely to be sued