IRC log of tagmem on 2003-01-20
Timestamps are in UTC.
- 20:02:06 [TBray]
- TBray has joined #tagmem
- 20:02:28 [Zakim]
- +DanielD
- 20:02:45 [Zakim]
- +DanC
- 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]
- prob
- 20:05:04 [Zakim]
- +Tim_Bray
- 20:05:06 [TBray]
- howdy
- 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]
- yes
- 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]
- http://www.w3.org/2003/01/20-tag
- 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]
- Regrets?
- 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]
- +DOrchard
- 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]
- http://www.petitesuites.com/
- 20:12:18 [Ian]
- ========================
- 20:12:24 [Ian]
- Draft agenda for ftf meeting:
- 20:12:30 [Ian]
- http://www.w3.org/2003/02/06-tag-agenda.html
- 20:12:45 [Zakim]
- +DanC
- 20:12:52 [Zakim]
- -DanC
- 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]
- Findings:
- 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]
- http://www.textuality.com/tag/uri-comp-2.html
- 20:17:36 [Ian]
- Comments from DC:
- 20:17:42 [Ian]
- http://lists.w3.org/Archives/Public/www-tag/2003Jan/0132.html
- 20:18:25 [Ian]
- ===========
- 20:18:33 [Ian]
- Agenda switch: Linking meeting
- 20:18:43 [Ian]
- Draft summary: http://lists.w3.org/Archives/Member/tag/2003Jan/0032
- 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]
- q?
- 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]
- q+
- 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]
- -DanC
- 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]
- q?
- 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]
- q+
- 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]
- q+
- 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]
- +TimBL
- 20:40:10 [Norm]
- I'd certainly sign up for the improvements TBray describes on XLink
- 20:40:12 [Ian]
- q?
- 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]
- q+
- 20:42:48 [Ian]
- q-
- 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]
- http://www.w3.org/2001/tag/ilist#URIEquivalence-15
- 20:44:07 [Ian]
- "How to Compare Uniform Resource Identifiers"
- 20:44:11 [Ian]
- http://www.textuality.com/tag/uri-comp-2.html
- 20:44:13 [Ian]
- DC comments:
- 20:44:16 [Ian]
- http://lists.w3.org/Archives/Public/www-tag/2003Jan/0132.html
- 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]
- http://lists.w3.org/Archives/Public/www-tag/2003Jan/0139.html
- 20:46:33 [Ian]
- [Next]
- 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]
- [Next]
- 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]
- http://www.w3.org/2001/tag/2002/webarch-20021206
- 20:48:22 [Stuart]
- q?
- 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 uri@w3.org requesting terminology change.
- 20:51:32 [Ian]
- [Next]
- 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]
- q?
- 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]
- q+
- 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]
- q+
- 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]
- help!
- 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]
- [Next]
- 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]
- ADJOURNED
- 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