IRC log of tagmem on 2003-01-20

Timestamps are in UTC.

20:02:06 [TBray]
TBray has joined #tagmem
20:02:28 [Zakim]
20:02:45 [Zakim]
20:03:04 [Norm]
zakim, who's talking?
20:03:16 [Zakim]
Norm, listening for 10 seconds I heard sound from the following: ??P0 (14%), ??P2 (19%), Norm (86%), DanielD (84%), DanC (4%)
20:03:20 [Norm]
zakim, mute danield
20:03:21 [Zakim]
DanielD should now be muted
20:03:51 [Norm]
zakim, who is danield
20:03:52 [Zakim]
I don't understand 'who is danield', Norm
20:04:15 [Ian]
zakim, danield is Ian
20:04:16 [Zakim]
+Ian; got it
20:04:29 [Norm]
Ian, I muted you because you were giving us musak
20:04:40 [Ian]
no probe
20:04:42 [Ian]
20:04:43 [Ian]
20:05:04 [Zakim]
20:05:06 [TBray]
20:05:35 [Ian]
zakim, who's here?
20:05:36 [Zakim]
On the phone I see ??P0, ??P1, Norm, ??P2, Ian (muted), DanC, Tim_Bray
20:05:37 [Zakim]
On IRC I see TBray, Zakim, Ian, Norm, PaulC, Stuart, RRSAgent
20:05:52 [Ian]
[Here are RF, TB, DC, SW, IJ, NW]
20:05:59 [Ian]
And PC
20:06:04 [Ian]
Am I missing anyone?
20:06:05 [Norm]
zakim, who's talking?
20:06:16 [Ian]
Regrets: CL
20:06:19 [Zakim]
Norm, listening for 10 seconds I heard sound from the following: ??P0 (52%), ??P2 (90%), Norm (81%), DanC (70%)
20:06:23 [Ian]
Unknown: TBL
20:06:24 [Norm]
zakim, mute danc
20:06:26 [Zakim]
DanC should now be muted
20:06:32 [Ian]
Initial regrets: DO
20:06:47 [Ian]
20:06:55 [Norm]
zakim, unmute ian
20:06:57 [Zakim]
Ian should no longer be muted
20:07:19 [Ian]
zakim, mute me
20:07:20 [Zakim]
Ian should now be muted
20:07:33 [Ian]
zakim, unmute me
20:07:33 [Zakim]
Ian should no longer be muted
20:07:39 [Norm]
zakim, ??p0 is PaulC
20:07:40 [Zakim]
+PaulC; got it
20:07:46 [Norm]
zakim, ??P2 is Roy
20:07:48 [Zakim]
+Roy; got it
20:07:49 [Norm]
zakim, who's here?
20:07:50 [Zakim]
On the phone I see PaulC, ??P1, Norm, Roy, Ian, DanC (muted), Tim_Bray
20:07:51 [Zakim]
On IRC I see TBray, Zakim, Ian, Norm, PaulC, Stuart, RRSAgent
20:07:52 [Ian]
Roll call: SW, NW, PC, DC [partly], RF, IJ
20:07:53 [Ian]
Regrets: CL
20:07:57 [Ian]
Unknown: TBL
20:08:00 [Ian]
Not yet: DO
20:08:10 [Ian]
Present: TB
20:08:16 [Norm]
zakim, ??P1 is Stuart
20:08:18 [Zakim]
+Stuart; got it
20:08:19 [Ian]
Accept 13 Jan minutes?
20:08:26 [Ian]
PC, RF: Fine.
20:08:31 [Ian]
Resolved: Accepted 13 Jan minutes.
20:08:36 [Ian]
This agenda:
20:08:42 [Ian]
20:08:47 [Ian]
SW: Comments?
20:08:55 [Ian]
PC: Do we have any reviews of arch doc?
20:08:56 [Ian]
IJ: No.
20:09:00 [Ian]
SW: No.
20:09:49 [Ian]
Next meeting?
20:10:10 [Ian]
Proposed: 27 Jan
20:10:15 [Ian]
20:10:22 [DanConn]
DanConn has joined #tagmem
20:10:43 [Ian]
NW: I will attend what I can on 27 Jan (at ftf)
20:10:48 [Ian]
20:10:52 [Ian]
Meeting planning
20:10:53 [DanConn]
27Jan: I'm available for telcon
20:10:55 [Zakim]
20:11:05 [Ian]
Hotel suggestions?
20:11:16 [DanConn]
I've got a reservation... at...
20:11:18 [Ian]
[For Irvine]
20:11:30 [Ian]
PC/DO: Hilton.
20:11:51 [Ian]
IJ/TBL/DC/CL staying at Petite Suites
20:11:55 [DanConn]
Hotel: Wooley Petitie Suites
20:11:55 [Ian]
20:12:18 [Ian]
20:12:24 [Ian]
Draft agenda for ftf meeting:
20:12:30 [Ian]
20:12:45 [Zakim]
20:12:52 [Zakim]
20:13:15 [Ian]
SW: I intend to call people to help flesh out agenda.
20:13:32 [Ian]
TB: I think that we have done reasonably well at powering through the issues. We have done poorly at moving the arch doc forward.
20:13:46 [Ian]
TB: We ought to measure our success at this meeting by progress on arch doc.
20:14:00 [Ian]
DC: Yes, a good goal.
20:15:06 [Ian]
PC: I think that we don't have agreement on what it should look like. I think people need to propose alternatives if unhappy with it.
20:16:32 [Ian]
[General agreement that text in advance of meeting is helpful]
20:17:05 [Ian]
20:17:06 [Ian]
20:17:21 [Ian]
TB: I will have a revision of Deep Linking before the end of the month.
20:17:30 [Ian]
"How to Compare Uniform Resource Identifiers"
20:17:34 [Ian]
20:17:36 [Ian]
Comments from DC:
20:17:42 [Ian]
20:18:25 [Ian]
20:18:33 [Ian]
Agenda switch: Linking meeting
20:18:43 [Ian]
Draft summary:
20:19:00 [Ian]
IJ: I would like TAG to approve this summary to make it public. I've heard no opposition from other participants.
20:19:05 [Ian]
SW: Civil meeting!
20:19:20 [Ian]
TB: No consensus, but I think we made progress in terms of identifying sources of disagreement.
20:19:23 [Ian]
TB: Two dominate others:
20:20:05 [Ian]
1) Whether the signal is something is a link should be inline in a document, or out of line (e.g., as done in hlink or clink). I think that the HTML WG feels strongly that the external approach should be at least allowed and possibly dominant.
20:20:36 [Ian]
2) Is it appropriate to have multiended link through several attributes? People see design problems; HTML WG still wants it.
20:20:49 [Ian]
20:20:58 [DanConn]
is that "can't live without it" requirement about mutiple links on one element a matter of record?
20:21:56 [Ian]
PC: Will summary be available?
20:22:03 [Ian]
IJ: I produced one; mostly derived from IRC log.
20:22:11 [Ian]
NW: I think TB has identified the two most contentious issues.
20:22:36 [Ian]
NW: I agree that the meeting was useful, I did leave a bit frustrated that we didn't get any farther.
20:23:30 [Ian]
IJ: I think the multiended issue was one about attributes, not multiended.
20:24:36 [Norm]
zakim, who's talking?
20:24:47 [Zakim]
Norm, listening for 10 seconds I heard sound from the following: Norm (66%), Tim_Bray (61%), Ian (28%), DanC (77%)
20:24:52 [Ian]
IJ: Second piece for me was more about not modifying the instance, less about link sheets.
20:25:05 [Ian]
TB proposal on moving forward:
20:25:11 [Ian]
TB: Do nothing.
20:25:30 [Ian]
TB: An issue has been raised. We made our arch concerns public. They have been ably and cogently summarized by SW.
20:26:14 [Ian]
TB: I think that the HTML WG has the responsibility of figuring out how to do hyperlinking in HTML, and they should do that. Not that a bunch of issues have been raised on the record, I think that W3C process will mandate that the HTML WG think about them and respond to those issues.
20:26:52 [Ian]
TB: I think that we wait for the HTML WG to act next.
20:26:56 [Ian]
zakim, mute DanCOnn
20:26:57 [Zakim]
sorry, Ian, I do not see a party named 'DanCOnn'
20:27:21 [Ian]
RF: Can we come up with a generic principle for describing why the multiple element is perferred?
20:27:40 [Ian]
TB: There are responses from Misha, Chris, TB on this. [And IJ recalls comments from TBL as well]
20:28:10 [Ian]
[Attributes on attributes was mentionede]
20:28:18 [Ian]
RF: Can we include some of this in the arch doc?
20:28:26 [Ian]
SW: E.g., in guidance on markup languages.
20:29:01 [Ian]
IJ: Anything in IETF doc?
20:29:11 [Ian]
TB: Nothing specific enough for this debate.
20:29:32 [Ian]
TB: There is a general principle that in XML markup languages, that if you have one, an attribute is ok. If you have several, then elements are preferable.
20:29:43 [Ian]
NW, TB: Good idea to talk about this in arch doc.
20:29:49 [Ian]
PC: What about list attributes (e.g., class)
20:29:53 [Ian]
(e.g., class in HTML).
20:30:23 [Ian]
TB: List of attributes is more work for programmers.
20:30:28 [Ian]
[List of values]
20:31:03 [Ian]
SW: I have mixed feelings about "doing nothing" at this point. What about producing a finding (even if it just articulates an opinion already expressed).
20:31:03 [Norm]
20:31:21 [Ian]
NW: I think TB's right - I'm not sure what next steps would be right now.
20:31:25 [Zakim]
20:31:52 [Ian]
NW: I can't think of any practical step at this time.
20:32:03 [Norm]
ack norm
20:32:14 [Ian]
IJ: What is scheduled at tech plenary re: linking?
20:32:26 [Ian]
PC: We meet this week to discuss the agenda.
20:32:46 [Ian]
PC: It was suggested that we not go into linking issues.
20:33:01 [Ian]
20:33:34 [Ian]
SW: Liam may organize a BOF.
20:34:05 [Ian]
PC: I'd like us to have a firm bring forward date.
20:34:55 [Ian]
TB: What about a one-line statement that we believe that the technical issues have been well-aired, and that those responsible for designing hyperlink syntax in various activities should be aware of them.
20:35:09 [Ian]
20:36:10 [Ian]
PC: I would like all parties to know where the other parties stand.
20:36:53 [Ian]
TB: We could send pointer to SW's summary to HTML WG comment list.
20:37:02 [Ian]
TB: I don't see benefit of writing this down again.
20:37:48 [Ian]
SW: Does the TAG still hold the same group opinion that we held in Sep 2002?
20:37:57 [Ian]
NW: I've not been moved.
20:38:09 [TBray]
20:38:29 [Ian]
RF: I believe that the multiend solution is preferred if there is no backwards compatibility issue.
20:38:55 [Stuart]
ack Ian
20:39:24 [Ian]
IJ: TB's approach of doing nothing means - no common syntax for links in XML?
20:40:07 [Ian]
TB: I think that xlink as written is better than some other solutions. But some good and plausible ideas have been suggested for improving XLink. I might change my mind on our previous statement in favor of an improved solution.
20:40:07 [Zakim]
20:40:10 [Norm]
I'd certainly sign up for the improvements TBray describes on XLink
20:40:12 [Ian]
20:40:18 [Ian]
ack TBray
20:41:27 [Ian]
[SW summarizes for TBL]
20:41:44 [Ian]
SW: My sense is that the TAG holds pretty much the same opinion as last Sep.
20:42:09 [Ian]
TBL: We should just keep an eye on what develops out of our link meeting. I'm glad that we focused on hypertext links at that meeting.
20:42:43 [Ian]
NW: I like PC's of setting a date to revisit the question, rather than open-ended.
20:42:45 [Ian]
20:42:48 [Ian]
20:42:54 [TimBL]
TimBL has joined #tagmem
20:43:01 [Ian]
NW: After the tech plenary.
20:43:15 [Ian]
IJ: 17 March?
20:43:45 [Ian]
Action IJ, SW: Bring xlinkScope-23 to agenda after tech plenary meeting?
20:43:47 [Ian]
20:43:57 [Ian]
# URIEquivalence-15
20:44:00 [Ian]
20:44:07 [Ian]
"How to Compare Uniform Resource Identifiers"
20:44:11 [Ian]
20:44:13 [Ian]
DC comments:
20:44:16 [Ian]
20:44:49 [Ian]
TB summarizes comments (passing over editorial, with which TB largely agrees).
20:45:20 [Ian]
TB on comment "er...what about 'identical'?"
20:45:51 [Ian]
TB: I agree with that DC that the draft isn't clear enough that two pieces of software might have different ideas of what's equivalent and be perfectly fine.
20:46:04 [Ian]
SW: See my proposed paragraph on this point.
20:46:15 [Ian]
20:46:33 [Ian]
20:46:49 [Ian]
TB: I think all specs in this space that are relevant are RFCs, but I'll check.
20:46:50 [Ian]
20:47:15 [Ian]
DC: "The TAG has decided to use the term "URI" to include
20:47:15 [Ian]
relative URI references. CRITICAL."
20:47:30 [Ian]
SW: I have a different recollection.
20:47:54 [Ian]
TB: I agree with SW on this.
20:48:18 [Ian]
Current editor's draft says:
20:48:21 [Ian]
20:48:22 [Stuart]
20:48:27 [Ian]
"The current document uses the term "URI" to mean, in RFC2396 terms, an absolute URI reference3 optionally followed by a fragment identifier. The TAG is working actively to convince the IETF to revise RFC2396 so that the definition of "URI" aligns with the current document."
20:48:49 [Ian]
RF: DC's comment is incorrect.
20:49:25 [Ian]
DC wrote: "The TAG has decided to use the term "URI" to include
20:49:25 [Ian]
relative URI references. CRITICAL."
20:49:44 [Ian]
TBL: What's the status of changes to 2396?
20:49:53 [Ian]
RF: I'm ok with the change, but requires quite a bit of drafting.
20:50:05 [Ian]
RF: I don't object to changing it.
20:50:10 [Ian]
TBL: I think this is the time to do it.
20:50:19 [Ian]
TBL: RF, do you need help. Please, please, please.
20:50:49 [Ian]
Proposed Action TB: Request that the change be made on the URI list.
20:51:09 [Ian]
RF: Send URI Equivalence to URI list as well.
20:51:30 [Ian]
Action TBL: Send email to requesting terminology change.
20:51:32 [Ian]
20:52:26 [Ian]
TB: I'll fix example://a/b/c/%7A [then] eXAMPLE://a/b/../x/b/c/%7a since there's an extra "x/".
20:52:39 [Ian]
RF: RFC doesn't let you make relative path changes to a relative URI.
20:53:06 [Ian]
20:53:37 [Ian]
TB: I think that if I encounter two URIs that differ only in scheme case, they are equivalent per the RFC.
20:53:45 [TBray]
example://a/b/c/%7A and eXAMPLE://a/b/../b/c/%7a
20:54:37 [Ian]
TB: RF, you are saying I can't lose the "../b/c"?
20:54:46 [Ian]
RF: Servers can do that.
20:54:59 [TBray]
actually, you can lose just the "../b"
20:55:46 [Ian]
TBL: The absolutizing algo allows this : given a base URI and an abs URI, you can relative the abs URI and then combine with a base URI and regurgitate the abs URI.
20:56:56 [TBray]
20:57:04 [Ian]
TBL: There are a set of functions that generate relative URIs that can then be used to produce abs URIs.
20:57:22 [Ian]
TBL: The spec defines those functions. It should define the axiom that if you do it and undo it, you get the same URI.
20:59:31 [TimBL]
Axiom: Abs(Rel(u1, base), base) == u1
20:59:51 [Ian]
ack TB
21:00:31 [Ian]
TB: 2396 says that the ".." semantics is only documented in the case of relative URIs. Is that intentional? Every Web robot on the world will change "b/../b" into "b"
21:00:39 [Ian]
RF: Or is it the server that does it?
21:00:44 [Ian]
TB: Robot does it.
21:00:56 [Ian]
TBL: What is the desired semantics?
21:01:54 [Ian]
RF: In reality, server can compress these. Browsers may treat these differently. We don't want the browser relativizing algorithm on every URI.
21:02:18 [Ian]
RF: Some schemes don't allow relativization at all.
21:02:23 [Ian]
TBL: But they don't use "slash".
21:02:25 [TimBL]
q+ to point out hat because we define things to be equivalent htat doe snot mean everyone has to cannonicalize everything
21:02:29 [Ian]
RF: But they might use ".." in the path.
21:03:34 [Ian]
TB, TBL arguing that inapplicability of "../" in abs path is inconsistent.
21:04:13 [Ian]
RF: What if the server considers these to URIs to refer to two different resources?
21:04:43 [TBray]
21:04:55 [Ian]
ack TimBL
21:04:56 [Zakim]
TimBL, you wanted to point out hat because we define things to be equivalent htat doe snot mean everyone has to cannonicalize everything
21:04:57 [Ian]
ack TBray
21:04:58 [Stuart]
ack TimBL
21:06:35 [Stuart]
From RFC2396 Section 4
21:06:37 [Ian]
RF: The standard is defined not in terms of equiv relationship, but what the browser does.
21:06:44 [Stuart]
The syntax for relative URI is a shortened form of that for absolute
21:06:44 [Stuart]
URI, where some prefix of the URI is missing and certain path
21:06:44 [Stuart]
components ("." and "..") have a special meaning when, and only when,
21:06:44 [Stuart]
interpreting a relative path. The relative URI syntax is defined in
21:06:44 [Stuart]
Section 5.
21:08:20 [Ian]
TBL Proposal: Standard should say that server must not consider "....b/../b" and "....b/" to be different.
21:08:41 [Ian]
TB: Implementations do this.
21:09:27 [Ian]
RF: Don't say in the standard that "b/../b" and "b/" are equivalent. Servers may consider them to be different.
21:10:33 [Ian]
TB: RF is saying that it's stupid for a server to treat "b/../b" and "b/" differently, but it can.
21:10:55 [Ian]
TBL Proposal: Equivalent to say that there's a canonicalization algo that clients should run.
21:11:07 [Ian]
TBL: Thus, servers can know what to expect.
21:11:16 [Ian]
TB: In fact, that's what clients do: cleanup.
21:11:32 [Ian]
RF: Some concerns about digest authentication.
21:12:45 [Ian]
21:12:47 [Ian]
21:13:24 [Ian]
RF: Servers send redirects back to client [Apache does this] after canonicalization of URI.
21:14:39 [Ian]
RF: We can try to resolve this problem in 2396. I suggest we make one URI "good" and the others "bad cousins"
21:14:43 [Ian]
TBL: That works for me.
21:14:50 [TimBL]
Roy: We could make abs URIs wil ../ in illegal
21:15:36 [Ian]
TB: The specific point w.r.t. to the finding: I think I need to weaken the claim w.r.t. 2396 until we change 2396 or roll this text into 2396.
21:15:41 [Ian]
RF: Or say "in the future..."
21:15:42 [Ian]
21:16:06 [Ian]
TB: I think that's it for critical errors.
21:16:17 [Ian]
SW: I'd like clarification of 2396 w.r.t. escaping.
21:17:40 [Ian]
TB: RFC2396 talks about octet-to-hex encoding, but not character-to-octet encoding.
21:18:22 [Ian]
TB: PC has raised the issue that popular software libs user uppercase.
21:18:40 [Ian]
PC: Some private email as well agreeing that libs do uppercase.
21:19:07 [Ian]
RF: I think that apache uses LC in general but I'd be happy to change to UC; doesn't matter to us.
21:20:33 [Ian]
TB: I'll change draft to UC since PC cares and nobody else seems to.
21:21:07 [Ian]
TB: "Good practice - when you have to hexify, use UC."
21:21:15 [Ian]
TBL: Fine if this is just good practice (not required).
21:22:00 [Ian]
SW: Move to adjourn.
21:22:15 [Ian]
Action TB: Do one more draft of URI equiv draft; then hand off to Ian.
21:22:17 [Ian]
21:22:21 [PaulC]
Stuart: I am in Redmond this week if you want to call me re F2F agenda.
21:22:36 [Ian]
RRSAgent, stop