IRC log of tagmem on 2006-03-21

Timestamps are in UTC.

17:57:17 [RRSAgent]
RRSAgent has joined #tagmem
17:57:17 [RRSAgent]
logging to
17:57:24 [ht]
Meeting: TAG
17:57:31 [ht]
Chair: Vincent Quint
17:57:36 [ht]
Scribe: Henry S Thompson
17:57:43 [ht]
Scribe Nick: ht
17:58:20 [ht]
17:58:20 [Zakim]
TAG_Weekly()12:30PM has now started
17:58:27 [Zakim]
17:58:31 [ht]
ht has changed the topic to:
17:58:39 [MoZ]
MoZ has joined #tagmem
18:00:00 [ht]
Excuse me for asking, MoZ, but who are you?
18:00:05 [Ed]
Ed has joined #tagmem
18:00:23 [Norm]
On my way...
18:00:34 [Zakim]
18:00:53 [raman]
raman has joined #tagmem
18:01:16 [raman]
zakim, who is here?
18:01:16 [Zakim]
On the phone I see ??P0, Ed_Rice
18:01:18 [Zakim]
On IRC I see raman, Ed, MoZ, RRSAgent, Zakim, Vincent, DanC_lap, Norm, ht, DanC
18:01:24 [noah]
noah has joined #tagmem
18:01:27 [Zakim]
18:01:30 [Zakim]
18:01:40 [Zakim]
18:01:42 [ht]
zakim, please call ht-781
18:01:42 [Zakim]
ok, ht; the call is being made
18:01:43 [Zakim]
18:01:46 [MoZ]
ht i'm new to W3C and looking around
18:01:46 [raman]
zakim, who is here?
18:01:46 [Zakim]
On the phone I see ??P0, Ed_Rice, DanC, [INRIA], TimBL, Ht (muted)
18:01:51 [Zakim]
On IRC I see noah, raman, Ed, MoZ, RRSAgent, Zakim, Vincent, DanC_lap, Norm, ht, DanC
18:01:59 [Zakim]
18:02:01 [Zakim]
18:02:02 [DanC]
Zakim, ??P0 is raman
18:02:05 [Zakim]
+raman; got it
18:02:11 [noah]
zakim, [IBMCambridge] is me
18:02:13 [Zakim]
+noah; got it
18:02:14 [ht]
Guys, we have a stranger on the channel, I believe
18:02:28 [DanC]
MoZ, do we know you?
18:02:32 [timbl]
timbl has joined #tagmem
18:02:38 [Zakim]
18:03:00 [MoZ]
nevermind i'm going
18:03:05 [Vincent]
Zakim, who is here
18:03:05 [Zakim]
Vincent, you need to end that query with '?'
18:03:20 [MoZ]
has a nice chat
18:03:25 [Vincent]
Zakim, who is here?
18:03:25 [Zakim]
On the phone I see raman, Ed_Rice, DanC, [INRIA], Ht, noah, TimBL
18:03:26 [Zakim]
On IRC I see timbl, noah, raman, Ed, MoZ, RRSAgent, Zakim, Vincent, DanC_lap, Norm, ht, DanC
18:03:30 [MoZ]
MoZ has left #tagmem
18:03:41 [Zakim]
18:03:50 [Zakim]
18:04:07 [Zakim]
18:04:12 [Vincent]
Zakim, INRIA is Vincent
18:04:12 [Zakim]
+Vincent; got it
18:04:18 [ht]
Topic: Administrative
18:04:41 [timbl]
A new member of the XML working group
18:04:47 [timbl]
Mohammed Z
18:04:54 [timbl]
18:05:15 [timbl]
Mohamed Z
18:05:45 [DanC]
(I regret that we didn't manage to be more friendly to Moz)
18:05:50 [ht]
zakim, who is on the call?
18:05:50 [Zakim]
On the phone I see raman, DanC, Vincent, Ht, noah, TimBL, Norm, Ed_Rice
18:05:54 [timbl]
(me too)
18:07:00 [ht]
vq: next telcon 28 March
18:07:09 [ht]
ht: Regrets for 28 March
18:07:42 [ht]
vq: Proposed scribe: DO, fallback, ER
18:08:11 [noah]
Regrets for April 4th, which is 2 weeks out. I'll be at the XML Schema WG meeting.
18:08:25 [ht]
vq: Additions to the agenda?
18:08:59 [ht]
... Brief summary of security wkshp from DC, 5 minutes at the beginning
18:09:33 [DanC]
er... has an encoding problem
18:09:38 [ht]
vq: F2F at Mandelieu, minutes at,
18:09:44 [ht]
18:09:49 [ht]
18:10:49 [DanC]
Content-Type: text/html; charset=iso-8859-1
18:11:06 [dorchard]
dorchard has joined #tagmem
18:11:25 [DanC]
(did you forget to spin around the 3rd time after sacrificing a chicken, ht? ;-)
18:11:41 [ht]
DanC, that must be it
18:12:57 [ht]
vq: No further comments. . . first part approved
18:14:11 [DanC]
(I prefer that the minutes of that meeting all live in )
18:14:47 [ht]
danc: Should we have cross-links?
18:15:00 [DanC]
+1 approve, ammended as VQ sees fit for hypertext-happiness
18:15:13 [ht]
vq: I'll copy and make links. . .anything else? OK, 2nd part approved
18:15:37 [ht]
vq: 3rd part?
18:15:54 [ht]
er: needs a list of those present
18:16:02 [ht]
vq: and regrets from HT
18:16:52 [DanC]
I nominate for the record of our Friday beach walk
18:17:16 [ht]
vq: I'll copy, and then tell DanC
18:17:33 [ht]
dc: And I'll obsolete the original
18:18:33 [DanC]
q+ to ask if anybody else blogged
18:18:33 [ht]
vq: OK, part 3 approved, will add links everywhere, and from the agenda
18:19:04 [DanC]
(my blog entry about France)
18:19:19 [DanC]
18:19:28 [ht]
Topic: Security Workshop
18:19:51 [ht]
dc: Alan Kotok produced a good trip report, but it's team-only :-(
18:21:05 [ht]
... OpenID (walked through at Edinburgh f2f), SKIP (covers more), both of these work by having a link from my homepage to an authetication server
18:21:45 [ht]
OpenID use 'openid.server' as the relation, DICS use 'dics::server' [scribe unsure]
18:22:02 [ht]
... standardizedFieldValues51 is relevant here
18:22:06 [DanC] standardizedFieldValues-51, RDFinXHTML-35, endPointRefs-47, siteData-36
18:23:03 [ht]
... Above is my message about this meeting -- InfoCard was also presented, it uses an EPR as a persona reference
18:23:18 [ht]
... Very interesting workshop
18:23:32 [timbl]
18:23:46 [ht]
... Lisa D (new area director from IETF) says there are three new internet drafts in this area which the TAG should be looking at
18:24:24 [ht]
hst: Will you follow that up and tell us?
18:24:26 [ht]
dc: No
18:25:49 [ht]
Action: ER to follow up and tell us the references
18:25:53 [DanC]
lisa D's name to appear on soonish
18:26:21 [DanC]
Lisa Dusseault <>
18:26:52 [DanC]
"this area" = http authentication
18:27:54 [ht]
dc: RDFinXHTML -- the upper part of SKIP includes exchange of claims, looked like subject/property/value, surely could be RDF
18:28:13 [ht]
... Infocard has a similar claims exchange, maybe similar issue, maybe via SAML
18:28:39 [ht]
... I keep missing Eve Maler's intro to SAML
18:29:04 [raman]
including expired SSL certs at TP:-)
18:29:08 [ht]
tbl: Any headline about a new direction
18:29:11 [noah]
A Google search takes me to , which says: "Negotiation is used to determine mutually acceptable technologies, claims, and requirements. For instance, if one party understands SAML and X.509 claims, and another understands Kerberos and X.509 claims, the parties would negotiate and decide to use X.509 claims with one another."
18:29:30 [noah]
That's certainly not reliable information, but it strongly suggests that Infocard optionally uses SAML.
18:30:27 [ht]
dc: 1) The padlock is _so_ broken, we should really fix that; 2) Banks are not losing so much from fraud that they are worried about that as such, but it fear about this is driviing folk away from online services and thus limiting the banks' enthusiasm for new services
18:30:59 [ht]
[diversion about invalid HTML on the web. . .]
18:32:02 [ht]
tbl: Versioning and what a language is -- HTML as a language isn't completely defined by its DTD, because that doesn't cover the fact that extra elements and attributes are allowed
18:32:11 [DanC]
q+ to recant... actually, HTML conformance _is_ relevant to the workshop, and was brought up by Charles M. of Opera
18:32:36 [ht]
dc: No it doesn't -- extra elts and attrs are not normatively allowed, just acknowledged as a part of common practice
18:33:19 [DanC]
(and here begins the unbounded discussion that I warned about.)
18:33:19 [ht]
tbl: Why did we do that?
18:33:38 [ht]
hst: because the dtd was the only thing available 5 years ok for making normative statements
18:34:19 [ht]
nm: schema wg is hoping to provide some functionality here, in terms of new breed of wildcard
18:34:49 [ht]
tvr: but the lower-case s schema isn't the issue, it's what the browsers actually do that matters
18:35:03 [timbl]
18:35:26 [ht]
nm: Sure, but we started this passage wrt the goal of saying formally what the browsers already do, and that's what we're trying to provide
18:36:29 [noah]
Tim is talking about describing abstract groupings like HTML blocks (div, element, etc.). Schema substitution groups exist today, and let you add things to existing blocks.
18:36:52 [ht]
tbl: CSS is an interesting point in this regard -- refers to abstract classes of elements, e.g. HTML-block, and specifies that title is not a block
18:37:22 [ht]
nm: So xml schema provides for this, but it's single inheritance (substitution group)
18:37:40 [ht]
tbl: single-inheritance is a problem
18:37:55 [ht]
... why did you do that?
18:39:01 [ht]
hst: Because as the architecture was spec'd, allowing multiple subst group membership would have required multiple inheritance of types, and we didn't know how to do it
18:39:01 [Vincent]
ack danc
18:39:01 [Zakim]
DanC, you wanted to ask if anybody else blogged and to recant... actually, HTML conformance _is_ relevant to the workshop, and was brought up by Charles M. of Opera
18:39:29 [Zakim]
18:40:17 [ht]
dc: Closing panel at workshop, browser people asked what they needed, the response from C M-N was "give me a spec. for the HTML you produce"
18:40:29 [ht]
... 'you' is the banks
18:40:52 [ht]
... They haven't even begun to notice validity as a desideratum
18:41:15 [ht]
tvr: They don't because they're not aware of any benefits
18:41:38 [ht]
dc: They need to be browbeaten about this, I intend to do so
18:42:15 [ht]
tvr: They don't see the immediate value, and trying to get validity sometimes actually gets in the way of what they're trying to achieve
18:42:50 [ht]
vq: DC, please ask for agenda item next time if further thoughts occur
18:42:53 [timbl]
... if the banks don't match the validator anyway
18:43:01 [ht]
Topic: New publications
18:44:02 [ht]
vq: DC has asked for help to get namespaceState draft published
18:44:24 [ht]
dc: I've been promised help from a team member on Wednesday
18:44:45 [ht]
nw: I'm confused, I thought we were just waiting for SoTD text, then it would be ready
18:44:48 [DanC]
s/ a team member/a team member/
18:46:10 [ht]
[hst, ndw, dc divert on minutiae of W3C publication process]
18:46:24 [ht]
Topic: metadataInURI31
18:46:25 [noah]
Latest metadataInURI draft in date space:
18:46:38 [ht]
vq: NM has been working on this . . .
18:46:40 [noah]
A summary of past work and some proposals for future work:
18:47:34 [ht]
nm: Basic issue - -should the TAG say anything about using the structure of a URI to represent metadata about a resource, and given that anyone has done this, whether others should rely on it
18:48:05 [ht]
... Long history, back to July 2003, Stuart Williams wrote a draft, lots of discussion, in spurts, thereafter
18:48:16 [ht]
... I've picked this up, time to take stock
18:49:03 [ht]
er: I liked your summary a lot, thanks
18:49:25 [ht]
... I also looked at the draft finding, there seem to be some suggestions, e.g. for removing parts 2 and 3
18:49:50 [ht]
nm: Yeah, there was debate about that, I actually (from off the TAG at the time) thought they shoudl stay
18:49:58 [ht]
18:50:23 [DanC]
18:50:24 [ht]
nm: We definitely need to get to grips with this from a fresh start
18:50:43 [ht]
... I think we should _not_ go back over the 100s of messages in the archives
18:50:49 [Vincent]
ack danc
18:51:01 [ht]
... Are we happy that we should _not_ do that?
18:51:17 [ht]
dc: Definitely not, there's far too much history for that to be cost-effective
18:51:18 [Norm]
What DanC said! :-)
18:51:31 [ht]
nm: Thanks, that's what I hoped
18:51:42 [ht]
... Next question -- what should the draft really say?
18:52:10 [noah]
18:52:55 [ht]
dc: I like the brevity of the four points, but I need a story. . .
18:52:57 [Norm]
18:53:11 [ht]
nm: Not to worry, this isn't the finding, it's just what the finding will end up with
18:53:30 [Norm]
18:53:38 [ht]
er: So this is close to the oriiginal finding -- how are they different?
18:53:45 [ht]
dc: Read them, please
18:53:48 [Norm]
I think these four points articulate a reasonable direction forward
18:54:41 [ht]
nm: [reads]
18:55:08 [ht]
nm: First bullet summarised: what you do in the privacy of your own server is your own business
18:55:29 [ht]
s/[reads/[reads first bullet from/
18:55:39 [DanC]
(I'm not comfortable with "Those with authority over resources" but I don't have a suggestion of something better; see earlier discussion of struggling to come up with an IRW paper)
18:56:07 [ht]
nm: The second bullet is direct from Stuart's draft [reads 2nd bullet from]
18:56:17 [ht]
q+ to ask a Dirk and Nora question
18:57:05 [ht]
dc: I know what this means, but I'm not convinced if anyone without my background with this issue would understand what it means
18:57:31 [Vincent]
ack ht
18:57:31 [Zakim]
ht, you wanted to ask a Dirk and Nora question
18:57:55 [ht]
18:57:56 [Norm]
18:59:07 [DanC]
q+ to offer "inference" and "risk" and such, rather than "Those with authority over resources"
19:00:13 [noah]
q+ to probe on Henry/Raman example of side of bus common practice
19:00:58 [ht]
hst: I'm concerned that this finding will be understood as saying the above URI can refer to a resource which is instructions for gettting from DanC's house to a local swimming pool without giving any grounds for complaint
19:01:02 [timbl]
q+ to agree with raman but to say you are on your own if you can't guess it
19:01:04 [Vincent]
ack danc
19:01:04 [Zakim]
DanC, you wanted to offer "inference" and "risk" and such, rather than "Those with authority over resources"
19:01:38 [ht]
tvr: I agree that although it's very hard to pin down, people _do_ have reasonable expectations based on what they read in URIs
19:02:29 [ht]
dc: I'm unhappy with putting the blame on "Those with authority over resources", I'd rather say that anyone who sniffs inside URIs does so at _their_ own refs
19:02:56 [Vincent]
ack noah
19:02:56 [Zakim]
noah, you wanted to probe on Henry/Raman example of side of bus common practice
19:02:57 [ht]
tvr: The ultimate conclusion of this is that we get nothign but humanly unreadable URIs, and surely that's wrong
19:03:32 [ht]
nm: The fourth bullet tries to address this issue -- there's always a cost to peeking inside URIs
19:04:44 [ht]
... This is a piece of the puzzle, but focusses on the risk for software, but that's an valid point -- software will be very fragile if it relies on being able to unpick URIs for substantive purposes
19:04:52 [DanC]
TVR: yes, I agree if you bake bizzare assumptions into software, you've got a problem.
19:05:15 [ht]
tvr: I get the point for software, but it's mostly _people_ who read URIs
19:05:23 [ht]
... there's a funny kind of balance
19:05:54 [timbl]
19:06:02 [ht]
dc: Consumers are licensed to peak into URIs, producers are constrained in how they produce URIs -- that improves usability, even if it isn't required
19:06:15 [Vincent]
ack timbl
19:06:15 [Zakim]
timbl, you wanted to agree with raman but to say you are on your own if you can't guess it
19:06:20 [ht]
... The fact is that the minter has complete authority, per the current specs
19:06:49 [ht]
tbl: We do have to be careful
19:07:13 [ht]
... I spend I lot of time looking at URIs, trying to find things that help me, e.g. understand what my bank is doing
19:07:21 [DanC]
s/Consumers are licensed/to the extent that Consumers are licensed/
19:07:32 [ht]
... or c.f. the difference between MapQuest and Google map uris
19:07:56 [ht]
... So on the one hand, it's dangerous, it may change, if you do you're on your own
19:08:27 [ht]
... Perhaps we could [missed it] -- we have a convention, for instance the ? convention between forms and server software
19:08:45 [noah]
I agree with what Tim is saying. I'm curious, in terms of the consumer's risk: aren't the issues already covered by Stuart's draft (modulo risk that I'd make things worse when rewording?)
19:08:48 [ht]
... Or communities of users and producers may have a convention
19:08:54 [raman]
q+ to add: where the provider wants to make it crystal clear, and where they want to obfuscate they will do what th edo
19:09:47 [ht]
tvr: MapQuest is excellent example -- whatever we write should bias people towards making the URI useful
19:10:05 [ht]
... MQ made a conscious decision, Google did too, in the other direction
19:10:10 [noah]
So, this seems to change Stuart's "A URI assignment authority MAY publish specifications detailing its URI assignment policies. "
19:10:36 [noah]
to "A URI assignment authority MAY publish specifications detailing its URI assignment policies, and indeed SHOULD do so when users are likely to benefit from being able to understand the metadata. "
19:10:41 [ht]
... We should turn the emphasis towards guidance towards doing things in an extensible way
19:10:50 [ht]
tbl: Extensible?
19:10:52 [noah]
(I would word that in a less intimidating way, but is that the core thought?)
19:11:03 [ht]
tvr: Yes, because it encourages unexpected uses
19:11:24 [noah]
q+ to discuss specific proposal typed in above
19:11:27 [ht]
[scribe missed an example from tvr]
19:11:31 [ht]
ack rama
19:11:31 [Zakim]
raman, you wanted to add: where the provider wants to make it crystal clear, and where they want to obfuscate they will do what th edo
19:11:45 [Vincent]
ack raman
19:12:07 [ht]
q+ to talk about fragility of opaque URIs
19:12:14 [Vincent]
ack noah
19:12:14 [Zakim]
noah, you wanted to discuss specific proposal typed in above
19:13:01 [raman]
Note that what we're saying is similar to the Ruby On Rails philosophy of "convention over configuration".
19:13:12 [ht]
nm: Leaving aside reducing the intimidation factor, is the kind of thing tvr is looking for a change per that above addition of "SHOULD ...."
19:13:13 [DanC]
(boy, it would be nice to discuss usability, robustness, even aesthetic issues along with software-broknenness-level issues. But now it feels like a book.)
19:13:32 [raman]
Here, the convention is that there is meaningful parts in the URL
19:13:39 [noah]
"A URI assignment authority MAY publish specifications detailing its URI assignment policies, and indeed SHOULD do so when users are likely to benefit from being able to understand the metadata. "
19:14:19 [ht]
dc: tvr is going beyond this, saying "make them nice"
19:14:45 [ht]
nm: The core of the finding has said "you're at risk if you make inferences for which you have no license in a spec."
19:14:56 [ht]
... I'm concerned not to lose that
19:15:35 [ht]
...So I should be careful w/o checkin for a spec when I see URIs on the side of a bus
19:16:19 [ht]
tvr: The MQ example may have a document which tells me how the URI is structured, or they may not (Google is starting to)
19:16:31 [ht]
... But it often comes along after the fact
19:17:08 [Vincent]
ack ht
19:17:08 [Zakim]
ht, you wanted to talk about fragility of opaque URIs
19:17:09 [ht]
... So saying "before you publish something that people might use as an API, document it carefully" will just slow everythign down unnecessarily
19:18:57 [noah]
Noah notes that we seem to have come a long way since the 2003 decision which appears to have been "Resolved: Accept issue matadataInURI-NNN with note that TAG thinks the answer is "no" and will explain what to do instead."
19:19:20 [noah]
I read that "no" as saying: assume they're opaque, don't peek. Round and round we go.
19:19:53 [ht]
hst: Getting expectations from URIs, and then having them fulfilled, or not, is an important part of how the web works, in my opinion
19:20:16 [ht]
... I'm concerned that the overall tone/focus of the finding is positive, rather than negative
19:20:43 [ht]
dc: I'm somewhat sympathetic, but don't see how to get there without three years for writing a book
19:20:53 [dorchard]
19:21:38 [ht]
nm: So what do I do now, it feels to me that there's a shift in direction here, I'm prepared to try to respond to that, but not sure that's what the group wants
19:22:30 [ht]
nw: I agree that there's a shift in emphasis, and I want to think about it a bit, but I'm comfortable to try to move a bit in this direction
19:23:43 [ht]
dc: we could focus on the software-brokenness story, and be careful and correct, but no-one would care a lot
19:24:18 [ht]
nm:.... documentation is good
19:24:42 [ht]
dc: In practice dictionaries and encyclopedias are already there, no additional documentation is needed
19:25:18 [DanC]
rather: all the dictionaries and encyclopedias in the world are part of the contract between URI minters and URI consumers whether they like it or not
19:25:22 [ht]
nm: I think I could try to provide some concrete words, which might help us see whether we want to move this way
19:25:22 [Vincent]
ack dorchard
19:25:26 [ht]
tvr: Yes please
19:26:30 [ht]
do: Wrt is the TAG moving -- the TAG membership has evolved, this is a healthy example of this, doesn't mean we were wrong before, but here's a new perspective which should lead to a better finding
19:26:49 [ht]
nm: I was just concerned that I didn't lose the history, I've been reassured
19:27:34 [ht]
vq: OK, that's a good place to stop for today, when can NM get us some more?
19:27:38 [ht]
nm: End of April
19:28:00 [ht]
q+ to mention new draft coming
19:28:29 [ht]
vq: Confirm DO to scribe next week
19:29:30 [ht]
vq: Suggest we come back to next week
19:29:49 [ht]
vq: ER and TVR volunteer to review
19:30:01 [Zakim]
19:30:39 [Zakim]
19:30:40 [ht]
dc: This is a revision of something we've seen before -- with two positive reviews we wouldn't need a long discussion
19:30:41 [Zakim]
19:30:42 [Zakim]
19:30:42 [Zakim]
19:30:48 [Zakim]
19:31:17 [ht]
19:31:31 [DanC]
yes, Yadis
19:32:56 [Norm]
Yet another damned intermidable session?
19:33:56 [Vincent]
ht, don't forget to generate the minutes
19:36:35 [ht]
rrsagent, set logs world-visible
19:36:47 [DanC]
RRSAgent, stop