See also: IRC log
TBL: I have an action to get onto the TAG's agenda discussions of what ISP's let users do, e.g. controlling mime-types. Not quite sure how best to do it.
SW: Send email?
(scribe missed Tim's response on the email suggestion.)
TVR: We should also think about people kludging around with text/xml as a mime type. Has to do with what browsers content sniff and what they don't.
SW: Draft minutes of the 10th are at http://www.w3.org/2001/tag/2008/01/10-minutes
... Any objections to approving them?
RESOLUTION: Minutes of 10 January 2008 at http://www.w3.org/2001/tag/2008/01/10-minutes are approved.
<timbl> Raman, One could argue that XML is, with namespaces, self-describing and so it should be delivered as application/xml or text/xml so that the XML architecture alone defines what sort of a document it is. Especially with namespace mixing.
SW: We have a meeting on the 24th, with Dave Orchard as designated scribe, but we're short of agenda topics. If I don't get more by Tues., we may cancel the call on the 24th.
SW: Noah had an action http://www.w3.org/2001/tag/group/track/actions/94
... Email fulfilling that is at http://lists.w3.org/Archives/Public/www-tag/2008Jan/0035.html
<Stuart> tracker... that's ISSUE-7
NM: Anyone have problems with marking the action done?
SW: Agreed, action is done.
(David Orchard joins the call)
NM: I think a key point in the email responses is that this stuff is happening with scripting and redirects today, so having declarative markup in the form of the ping attribute is a good thing.
DC: I think using GET is OK for this. Don't have a strong opinion. We should leave the action on the someday.
<DanC> (i.e. I'm not ready to close the issue again just yet.)
HT: It's an error in logic to say that because scripts are used to do this, making an explicit attribute has no architectural downsides. There are all sorts of things you can do in script that aren't good Web arch. When you make an attribute, you imply "do this". I don't necessarily think ping is a bad thing, but the script precedent is the wrong argument.
<Zakim> noah, you wanted to say we need to keep issue a bit on the front burner, since we've just invited discussion.
NM: I think we need to keep some active attention to this. If nothing else, we just invited discussion.
NW: Not much to add. I agree with Henry that the fact that script is being used doesn't make the case one way or the other. Also, as I said last week, I have some skepticism that this will be sued.
<DanC> (I note our discussion seems to be more about requirements for PING rather than whenToUseGet, i.e. whether PING should use GET or POST)
TVR: I think this is not just about UI. It's more than that, and more than HTML-specific. So, I don't really agree with David Baron's response at http://lists.w3.org/Archives/Public/www-tag/2008Jan/0036.html
TBL: I asked on the list about using UDP.
<DanC> (mnot pointed out that UDP doesn't go thru firewalls straightforwardly... i.e. we're back to NAT vs IPV6)
NM: Responses you got were 1) UDP doesn't have specified semantics for this and 2) firewalls don't know about this
<Zakim> noah, you wanted to ask a bit more about GET vs POST
TBL: On point 1, you grab a port and define the semantics. Seems an abuse of the Internet to do something that's both high traffic and statistical (occasional losses don't matter) with a high-overhead connection-oriented approach.
TVR: I agree. Tim raises a core question: issues like this shouldn't be treated primarily in the context of a markup-specific specification. Knowing how Firefox works is good. Writing down specs is good. There's a risk of baking in too early.
HT: How can they use "options". That's supposed to be idempotent.
<Zakim> noah, you wanted to ask a bit more about GET vs POST
<scribe> scribenick: DanC
NM: where do you draw the line on GET vs POST? clearly GET is not for debiting my credit card balance, but I'm a little surprised that people say GET is OK for counting.
<scribe> scribenick: noah
<DanC> (careful with the quanitifiers; nobody is saying anything about "empty post for all resources")
<DanC> (nobody is talking about reliable accounting anyway; it's statistical)
<noah_> (added during editing of minutes -- actually, I think Roy's point is that with the attribute there, malicious sites can trick you into sending an empty post to URIs that don't have the intended semantic. So, in that sense, I think the quantifier is "all" resources.)
<Zakim> dorchard, you wanted to say the firewall problem won't be an issue because few sites will implement
DO: I don't think the firewall problems with UDP are that bad. Opening firewalls to UDP seems not that hard.
<DanC> (but the few sites that implement are going to care a *lot* about the whole AOL userbase that's behind one firewall, IIRC.)
<noah_> I wonder about home routers and the like.
<Stuart> what about the firewalls closer to the client or mid-net
<Zakim> DanC, you wanted to note the UDP bit falls into the tragedy-of-the-commons pile... i.e. invidual actors can get their job done better in the short-term using http/TCP; while it's
DO: I agree with Raman that it's not about UI at all. I think we should keep this on the front burner and be active.
<Zakim> timbl, you wanted to talk about effects under/over th hood
<DanC> (the Stevens book is the classical text on TCP/IP and UDP, IIRC.)
DC: The "use UDP" falls out of p.47 of Stevens' book ("TCP/IP Illustrated" by Richard Stevens and Gary Wright), but saying that won't make all the users do it. Then again, if people start doing pings with connection oriented protocols, the overhead could be big. Not sure what to do.
<DanC> (Steven's books seem to be http://www.kohala.com/start/#books )
<DanC> by "p. 47" I just meant "straight out of TCP/IP textbooks"
TBL: Clearly counting GETs is a risky thing to do. When you are instrumenting things inside of HTTP, you're sort of at two layers.
<noah_> Yes, of course, but these folks want to do advertising billing based on this stuff, and probably aren't OK with a big fraction of their hits being swallowed by caches.
<DanC> ( TCP/IP Illustrated, Volume 1: The Protocols, Addison-Wesley, 1994. )
<Zakim> ht, you wanted to raise the http bis issue
TBL: I don't want to argue for GET for two reasons 1) I prefer UDP 2) clearly there are problems with cacheing and proxying.
<DanC> (there's a whole bunch of work on counting GETs... there used to be internet drafts on HTTP extensions for HTTP proxies to report aggregate counts and such. I think that stuff is the subject of huge piles of academic research, these days.)
HT: The section on in the draft HTTP 1.1 RFC update on safe and idemptotent operations seems at odds with with what we're talking about. See: http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-03.html#rfc.section.9.1
... Let's say I'm going to put a CGI script at the URI of the w3c home page, and only changes member of the day every 1000 gets. That seems fine to me. It sure seems to violate 9.1.2 in the draft RFC, because the requests certainly aren't idempotent.
TBL: But the user hasn't bought into that contract.
HT: Yes, I agree, that's what I think too, but section 9.1.2 doesn't account for that being OK. When I read 9.1.2, incrementing a counter seems a side affect in my book.
DC: At the protocol level, you can't tell.
<DanC> (indeed, the visible counters run counter to the HTTP spec. they're an abuse.)
<ht> OK DanC, we're in agreement -- _should_ they be ruled out by the HTTP spec.
<ht> Why? Counters are benign. . .
<ht> I understand that they are misleading, but not seriously so
<DanC> no, counters are not benign. they work against caching. they're expensive for the community.
<ht> OK, so _invisible_ counters are benign?
<DanC> I think so; might have to hear about a specific example to be sure
<Stuart> DanC, so... is W3C member of the day... benign?
<DanC> now we're twisting, so I'm struggling. There are 400+ representations of http://www.w3.org/ . that's costly, but the community seems OK with the cost. one could say likewise about visible counters... "there are 99,999 representations of this resource". hmm.
TBL: Accounting GET accesses is fine.
NM: Yes, but we have to admit that the accounting semantics you get with GET are very different from what you POST gives you.
TVR: Yes, and people use rather sophisticated heuristics, like counting multiple requests in short period differently from ones that are widely spaced.
<ht> Stuart is right, OPTIONS is the now-proposed vehicle for the Access-control exchange, my confusion
SW: I don't see a particular action item at this point. Is there a tag blog article?
TVR: I think we should help focus the www-tag discussion on the non-UI aspects. I'm a bit worried that the discussion would get sidetracked if people felt "this is a UI issue, and that's not the TAG's main focus"
SW: OK, I'll do something, but we won't record it as a formal action.
SW: This is back on the table due to a post from Dan http://lists.w3.org/Archives/Public/www-tag/2008Jan/0033
DC: The Cool URIs document has been revised. The question is, have Norm's comments been addressed?
NW: I'm a bit swamped with other things, so can't do a review immediately.
DC: Maybe we should request an extension. When can we get comments back?
NW: I'm aiming for before next Thursday.
SW: Tim, you gave them some comments too.
<jar> I plan to review cool uris before the 21st, FWIW
DC: I think Tim sent mail on behalf of "the bunch of us"
... I feel I should doublecheck Tim's comments.
SW: By next week.
... Seems like a one week extension. Longer might help more. I guess I'll ask for one week extension.
NM: I thought they accounted for our comments. Ah yes, at the bottom they say "all TAG comments addressed"
SW: But, I think they only mentioned Norm's.
<scribe> ACTION: Dan to ask SWEO working group for one week extension for review of their document [recorded in http://www.w3.org/2008/01/17-tagmem-minutes.html#action01]
<trackbot-ng> Created ACTION-95 - Ask SWEO working group for one week extension for review of their document [on Dan Connolly - due 2008-01-24].
(Scribe notes that Jonathan Rees is in fact on the call.)
<Norm> ACTION: Walsh to review latest draft with respect in particular to his earlier comments [recorded in http://www.w3.org/2008/01/17-tagmem-minutes.html#action02]
<trackbot-ng> Created ACTION-96 - Review latest draft with respect in particular to his earlier comments [on Norman Walsh - due 2008-01-24].
<timbl> I have it on my agenda -- just things happen.
JR: We've had some calls. Alan Ruttenberg, David Booth and I seem to be on the hook to try and write down some RDF. The core question is: what triples can or should you infer from HTTP interactions. We want both directions: what can you infer from the interaction, but also from the application side, what do you want to get?
... I'll point people to our wiki pages and post here in IRC.
SW: Thank you, Jonathan.
<jar> AWWSW home page: http://esw.w3.org/topic/AwwswHome
<trackbot-ng> ACTION-85 -- David Orchard to produce another draft of Passwords in the Clear finding, based on comments from 15 November telcon, publish it and invite comment -- due 2007-12-06 -- OPEN
DO: I think I have an overdue action on passwords in the clear. Intending to, just haven't managed to get to it. Will do eventually I'm sure.
SW: Please update the due date.
DO: I'll reset it for 2 weeks from now.
<DanC> ACTION-85 is now due 2008-01-31
SW: I'll try and get to my overdue action on CURIE's this week. You can see I'm active on my action on F2F time.
<trackbot-ng> ACTION-92 -- Tim Berners-Lee to consider whether or not he wants to post an issue re: POWDER/rules -- due 2007-12-20 -- OPEN
SW: Tim, have you been looking at your action #92 on Powder http://www.w3.org/2001/tag/group/track/actions/92
TBL: I'm afraid not. I don't think I've seen this before.
<DanC> comes from http://www.w3.org/2001/tag/2007/12/13-minutes
<jar> powder + rules is actually quite interesting.
DC: This action came from the 13 Dec. meeting, and the records say you were there ( http://www.w3.org/2001/tag/2007/12/13-minutes )
HT: I think this has to do with how you specificy collections of URIs in POWDER and in access controls.
<Zakim> DanC, you wanted to note POWDER design progress in ways that I'm not entirely comfortable with
<DanC> "POWDER : my rabbit" http://lists.w3.org/Archives/Public/www-archive/2007Dec/0058.html
DC: (see links from Dan above) The POWDER use case is that some "Good Housekeeping" group says a certain group of pages is OK for 13 year olds. You need to say who said that and why. There was discussion of reification from RDF, which is known to be problematic.
<ht> zakim HT.a is me
TBL: We said you can do it in either XML or RDF and convert. Then you can explain the relationships in OWL.
(Scribe isn't following this quite well enough to record this accurately.)
<DanC> (what timbl was talking about involves standardizing the log:uri level-breaker.)
TBL: We encouraged them to put the ratings into a document. Then you can get provenance by saying things like "this document comes from so and so". By talking about the document, you avoid the need for reification.
DC: I don't think he's using documents for the provenance. I also think they're using GRDDL on RDF/XML, which makes my head spin a bit.
SW: I think he's trying to give a story to those who need a hard core RDF model.
... OK, this is a side discussion from the overdue actions topic. Is there still an action?
DC: I think it could be withdrawn.
SW: I will withdraw it.
... Tim can decide whether to come back to this.
... In December we had the whole access control thing, which also talks about collections of resources, and we were concerned about the differences. Can't quite decide whether I have the time/energy to push for getting this fixed.
<Zakim> dorchard, you wanted to mention XACML
DO: While research the access control stuff, I took a look at XACML. They've got a very interesting policy language, with implementations, etc. They have a rule combining algorithm that looks very nice. I took part of the English and pseudo code and proposed it for the access control stuff, but so far I'm getting pushback.
... I still think the XACML work is an interesting and useful base.
<timbl> Pointer to the XACL spec you read?
<DanC> (yes, XACML has come up in our semweb policy research stuff now and again; I still haven't studied it as much as I perhaps should... but... yeah... I don't really feel welcomed by PDF specs.)
DO: I was particularly interested in their Appendix C on combining algorithms for rule sets. This is exactly what the access control spec does.
TBL: Does the design guarantee things about the finished system that are nice, or is it just that the rules look appealing?
DO: Don't know.
<DanC> (our research group has something really cool called AIR... http://dig.csail.mit.edu/2008/Papers/IEEE%20Policy/air-overview.pdf )
<DanC> (nifty justification browser in tabulator.)
<dorchard> Hal's responses:
<dorchard> hal_lockhart: not sure I understand question - XACML has properties that no other ac system can match
<dorchard> hal_lockhart: primarily about scaling
<dorchard> hal_lockhart: xacml is a calculator - takes info as given
<dorchard> hal_lockhart: solves ac problem, depends on env for security guarantees
SW: I've posted a new WBS form about scheduling for Bristol in the May/June timeframe.
... There are quite a few constraints.
... This focusses on Bristol in the spring.
<ht> 19--21 works for me
<Norm> There you go, over constrained!
<dorchard> 19th is Victoria day holiday in Canada.
SW: I'll look for more survey results, then suggest something.
DC: I'm really interested in the proposal for KC in Sept.
SW: You had some commitment from Tim.
... Norm suggested 2 weeks earlier.
NW: Just to spread meetings more evenly.
<DanC> "Proposed 23-25th September 2008, Kansas City (Tue-Thu)" from the agenda
DC: But I want Tim there, and he can make the 23rd.
<raman> I'd find it more useful to use the remaining time talking about tagsoup.
<raman> calendar discussions by voice are highly unproductive
DC: I saw more consensus on 24-26
<DanC> ... but I misread it.
DC: Anyone have preferences on Tues-Thurs vs. Wed.-Fri.?
TBL: Did I agree to this?
DC: Yes, you said prefer.
SW: We of course haven't heard from those who will be elected soon.
<jar> i need to go, sorry.
DC: Planets are lined up to publish HTML spec 22 January. It has a lot of stuff all wrapped together.
ALL: (...there was some more informal discussion, but too rambling to minute...)