Time stamps are EDT
[15:02:53]
<Ian> Scribe: IJ
[15:02:59]
<Ian> Roll: All present but CL
[15:03:02]
<TimBL> RRSAgent, pointer?
[15:03:03]
<RRSAgent> See http://www.w3.org/2002/07/08-tagmem-irc#T20-29-54
[15:03:04]
<Ian> Agenda comments?
[15:03:35]
[15:04:02]
<Ian> Regrets next week? None
[15:04:03]
[15:04:36]
<Ian> Next meeting 22 July
[15:05:03]
<Ian> SW: DO, last week, group said it would not have quorum rules.
[15:05:09]
<TBray> intermittent dull roar in background
[15:05:14]
<DanC_> order? is somebody suggesting the record is inaccurate?
[15:05:26]
<DanC_> this seems like an agenda request, not a fix of the minutes.
[15:05:36]
[15:05:38]
[15:05:42]
<Ian> ....Stuart...
[15:05:49]
<Ian> ack DanC
[15:05:50]
<Zakim> DanC, you wanted to make a point of order
[15:05:51]
[15:06:25]
<Ian> Accept minutes from last week?
[15:06:29]
<Ian> SW: Accepted.
[15:06:34]
<DanC_> hmm... perhaps review of minutes should go before review of agenda.
[15:06:40]
<Ian> Action 1. IJ: Find out whether the W3C Comm Team expects to have a publishing moratorium in August.
[15:06:43]
<Ian> IJ: No moratorium
[15:07:00]
<Ian> (Learned this morning)
[15:07:08]
<Ian> ----------
[15:07:10]
<Ian> Arch document
[15:07:10]
[15:07:12]
[15:07:22]
<Ian> 1. ACTION TBL 2002/05/05: Negotiate more of IJ time for arch doc
[15:07:44]
<TBray> seems like we have a dull roar whenever Stuart's not talking
[15:07:46]
<Ian> TBL: I would like to keep this on the back burner (for 30 days).
[15:07:59]
<Ian> TBL: I think we've made the point, but in the fall, a few things happen.
[15:08:12]
<Stuart> q?
[15:08:13]
[15:08:35]
<Ian> TB: What provoked this was decision last week to have first public WD soon. Some question about IJ's availability a roadblock. Anything can we do? This issue is material to getting a spec out.
[15:08:59]
<TBray> plus Ian's on vacation 2nd half of August
[15:09:23]
<Ian> DC: I would rather process doc go to sleep for 2 months than TAG.
[15:09:29]
<Norm> 1
[15:09:30]
<Norm> +1
[15:09:31]
[15:09:52]
<Ian> DC: Please push this at AB ftf meeting.
[15:10:01]
<Ian> 2. ACTION RF 2002/06/24: Write a paragraph on technical and political aspects of URIs and URI References.
[15:10:15]
<Ian> RF: I touched on this on mailing list, but this para is 2nd priority to the URI spec itself.
[15:11:08]
<Ian> Is this on critical path for moving arch document forward?
[15:11:15]
[15:11:19]
<Ian> RF: I hope not.
[15:11:39]
[15:11:49]
<Ian> 3. Action TB, DC 2002/07/08: Propose text for section 1.1 (URI Schemes)
[15:11:51]
<Ian> TB: Done.
[15:12:04]
<Ian> 4. Action CL 2002/07/08: Propose text for section 2 (Formats). Deadline 30 July. [Not done]
[15:12:27]
<Ian> IJ: I have started incorporating TB text.
[15:12:42]
<Ian> TB: I am beginning to question whether it's worthwhile talking about varying properties of URIs.
[15:12:50]
<Ian> IJ: I have put SW's table in arch doc appendix for now.
[15:13:08]
<Ian> TBL: The important arch point is that these properties vary.
[15:13:28]
<Ian> DC: I disagree with the way the table answers the question.
[15:13:44]
<Ian> TBL: Disagreeing with column names or cell contents?
[15:14:01]
<Ian> DC: I disagree with TBL's conclusion that http points to document.
[15:14:13]
<Ian> TBL: My opinion is that you can't put "any" there since there's an open issue.
[15:14:51]
<Ian> TB: I think this belongs in an appendix.
[15:15:23]
<Ian> SW: I'm fine with people disagreeing on the contents of the table (for now)
[15:15:40]
<Ian> TBL: "Decentralized" is a bit of a political thing...
[15:15:43]
<Ian> DC: Quite.
[15:15:53]
<TBray> q+
[15:15:54]
[15:15:55]
<Ian> TBL: Subject to ongoing discussion as to the contents, I think the table is a useful thing.
[15:16:42]
<Ian> TBL: I'd like to generate table from RDF.
[15:17:08]
<Ian> Action DC: Regenerate this table from RDF (looking closely at contents of cells).
[15:17:23]
<TBray> q?
[15:17:25]
[15:17:30]
<Ian> ack TBray
[15:17:31]
[15:17:48]
<Ian> TB: I think it's worth discussing the role this thing takes in the arch document. I've seen the core of the arch document to be the assertions.
[15:18:20]
<Ian> TB: One key arch principles is that you shouldn't invent URI schemes. One good reason is that software is expected to handle them.
[15:18:44]
<Ian> TB: I'm wondering what the reason is for having a table in the arch document. I think the table is useful (somewhere). Does it have normative force? It will change over time.
[15:18:50]
<TimBL> q+
[15:18:51]
[15:18:52]
<Ian> q+
[15:18:54]
[15:18:57]
<Ian> ack TimBL
[15:18:58]
[15:19:09]
<Ian> TBL: I think this is as normative as the rest of the document.
[15:19:24]
<Ian> TBL: We should say you shouldn't re-invent the while.
[15:19:45]
<DanC_> (actually, you don't have uuid, timbl; it's not registered. Er..hmm... maybe it is, under urn:_
[15:19:47]
<DanC_> )
[15:20:05]
<Ian> TBL: If you are proposing a new URI scheme that has properties of scheme s, then use s.
[15:20:44]
<Ian> TB: So, the arch doc should include a list of some well-known URI schemes with properties to aid people in not inventing new ones?
[15:20:49]
[15:20:50]
[15:20:51]
<Ian> TBL: Yes, also to raise attention about some schemes.
[15:20:55]
<Ian> TB: Ok, that sounds plausible to me.
[15:21:17]
[15:21:18]
[15:21:21]
<Ian> IJ: I was going to suggest leaving in an appendix for now, and deciding later whether to pull out.
[15:21:46]
<Ian> IJ: Good to have clarification on the meaning of the columns.
[15:21:48]
<DanC_> [note to self, for ation: a possible corrollary of table with props: if you want an admin hierarchy, use DNS.]
[15:22:59]
<Ian> TB: "Resource state dynamics"?
[15:23:02]
<Ian> TBL: Is this just persistence?
[15:23:45]
<DanC_> [note to self: "fixed content resource"? column]
[15:24:02]
<Ian> TBL: Column heads: Persistence and Dereferenceability
[15:25:16]
<Ian> IJ: What values would one find for each column (where possible to enumerate)?
[15:26:05]
<DanC_> [note to self: re static: are there any future network messages that can show a different state of the resource? no, not for news: articles]
[15:26:47]
<Ian> TB: What about text I submitted?
[15:26:51]
[15:26:53]
<Ian> DC: I disagree on the first sentence.
[15:26:57]
[15:27:22]
<Ian> " 2. A URI identifies an abstraction for which there is a time-varying conceptual mapping to a (possibly empty) set of representations that are equivalent.
[15:27:22]
<Ian> "
[15:27:30]
<TimBL> http://www.w3.org/DesignIssues/Generic.html
[15:27:30]
<Ian> DC: Varies by more than time.
[15:27:44]
<Ian> TB: Why is time specially distinguished?
[15:27:48]
<Ian> RF: People keep forgetting it.
[15:27:52]
<TimBL> time, language, representation, ....
[15:27:54]
<Ian> DC: Not sure if I definitely object.
[15:28:36]
<Ian> PC: If DC's concern is that people forget that is to put in a second sentence.
[15:28:39]
<Stuart> q?
[15:28:40]
[15:28:43]
<Ian> q-
[15:28:43]
<DanC_> my www9 presentation on this mapping between URIs and content: http://www.w3.org/2000/Talks/www9-larch/all.htm
[15:28:43]
[15:28:51]
<Ian> TBL: I'd like parameters to be tabulated.
[15:28:58]
<TimBL> Table head: What can resoirce vary under?
[15:29:00]
<Ian> TB: I think DC's objection is correct.
[15:29:08]
<Ian> TB: Leans to heavily on time.
[15:29:34]
<Ian> TB: "A URI identifies an abstraction for which there is a conceptual mapping to a (possibly empty) set of representations that are equivalent. May vary ...."
[15:30:26]
<Ian> Action TB: Clarify first sentence.
[15:30:38]
<DanC_> -> http://www.textuality.com/tag/s1.1.html
[15:31:16]
<Ian> DC: A lot of naming issues are justified architecturally by economics. E.g., costly to deploy new URI schemes ubiquitously.
[15:31:31]
<Ian> TB: My text says that.
[15:31:54]
<Ian> DC: Why have absolute naming in the first place? It might be worthwhile to tell story about how absolute email addresses came to be.
[15:32:20]
<Ian> DC: Used to be the case that you have to go through several machines (susie!bob!ian...) to get to ian.
[15:33:06]
<TBray> aaah... watmath!decvax!anywhere as I recall...
[15:33:49]
<Ian> TBL: Root emerged. The Web tree-ified.
[15:34:10]
<Ian> DC: The point is that URIs serve this need in communication (to refer to things).
[15:34:34]
<Ian> TBL: DC explaining why it's useful to have absolute names - why URis mean the same thing wherever you are.
[15:34:43]
<Ian> s/URIs/absolute URIs/
[15:35:09]
<Ian> TB: Principle - "Absolute addressing is better than context-sensitive addressing."
[15:35:19]
<Ian> DC: More subtle than that - cheaper....
[15:35:20]
<TimBL> Zakim, temporarily mute PaulC
[15:35:21]
<Zakim> sorry, TimBL, I do not see a party named 'PaulC'
[15:35:27]
<Norm> The ability to provide absolute addressing is better...
[15:35:29]
<Ian> DC: This is the adopted principle - that is the way it is.
[15:35:37]
<TimBL> Zakim, who is here?
[15:35:38]
<Zakim> On the phone I see TimBL, Stuart, Norm, DanC, Ian, TBray, DOrchard, Roy, Paul
[15:35:40]
<Zakim> On IRC I see DaveO, TBray, Zakim, Roy, Stuart, DanC_, Norm, Ian, RRSAgent, TimBL
[15:35:47]
<TimBL> Zakim, temporarily mute Paul
[15:35:48]
<Zakim> Paul should now be muted
[15:35:50]
<Ian> Action SW: WRite down this arch principle.
[15:35:57]
<Ian> zakim, unmute paul
[15:35:59]
<Zakim> Paul should no longer be muted
[15:36:02]
<Zakim> Paul should now be unmuted again
[15:36:15]
<TBray> Paul came back but the name didn't
[15:36:15]
[15:36:24]
<TBray> er the noise not the name
[15:36:42]
<Ian> PC: The story DC started to tell (about email addresses - routing in email address). Doesn't this go against another arch principle - shouldn't be centralized name serverse?
[15:36:47]
<Ian> DC: Yes, there is a subtlety here.
[15:36:50]
<Ian> DC: There is a tension.
[15:37:06]
<Ian> TBL: DNS as weakness in Web.
[15:37:06]
<TBray> zakim, mute TBray
[15:37:07]
<Zakim> TBray should now be muted
[15:37:21]
<TBray> zakim, unmute TBray
[15:37:22]
<Zakim> TBray should no longer be muted
[15:37:24]
<Ian> PC: We all decided that DNS was better.
[15:38:30]
<Ian> SW: If you are going to assert that DNS is a weak point, would you be bound to propose a substitute?
[15:39:03]
<Ian> DC: The ideal URI scheme (from one end) is that everyone generate random numbers. But a pain since you can't write them down, hard to search through. So DNS is easier.
[15:39:17]
<Ian> DC: TBL, you have to write the story, not just expect people to buy it.
[15:40:29]
<TBray> for the record, is there any way to improve the audio quality? I'm getting a headache
[15:40:39]
[15:41:10]
<Ian> DC: In progress; awaiting a reply.
[15:41:39]
<Ian> TB: What's going on here: different answers from Mark Baker, Keith Moore, Michael Mealing?
[15:41:53]
<Ian> DC: Sometimes hard to get answer from IETF.
[15:42:13]
<DanC_> gold star for Bray providing text for 1.1, btw.
[15:42:36]
[15:42:37]
[15:43:07]
<Ian> TB: How do we get from here to first public WD 15 August?
[15:43:40]
<Ian> DC: I'm happy to have IJ chew on text until early August and then ship it.
[15:43:41]
<TimBL> "[DNS centralization and exploitation] does serve as a good illustration of the way a single centralized point of dependence put a wrenchin the gears [...] and be exploited [...]for power and profit ---- "Weaving the Web" p129
[15:43:58]
<Ian> q+
[15:43:59]
[15:44:04]
<Ian> DC: I have no lower bound on quality.
[15:44:07]
<Ian> ack DanC_
[15:44:08]
[15:44:12]
<Ian> ack DanC
[15:44:14]
[15:44:18]
<Ian> TB: I do have a lower bound on quality.
[15:44:52]
<Ian> IJ: Today at Comm Team talked about press release for first public WD.
[15:44:58]
<Ian> DC: No thank you.
[15:45:02]
<Ian> DO: I agree with DC.
[15:45:04]
<Ian> PC: I agree with DC.
[15:45:13]
<TimBL> I also agree with DC
[15:45:19]
<Stuart> +1
[15:45:20]
[15:45:38]
<Ian> IJ: I told Janet document would be rough.
[15:45:52]
<Ian> TB: You could achieve higher quality by removing partial sections.
[15:46:13]
<Ian> DC: You make it sound like shorter is easier, but that's not my experienc3.
[15:46:56]
<Ian> q?
[15:46:58]
[15:47:01]
<Ian> q-
[15:47:02]
[15:47:17]
<Ian> SW: Where would we have to be to have something that would make Janet happy.
[15:47:53]
<Ian> TB: If we do something that has WD on the top, it will get press coverage anyway.
[15:48:01]
<Ian> DC: If we do a press release, I'll have to take press calls.
[15:48:48]
<Norm> q+
[15:48:49]
<Ian> PC (changing mind): I'm fine if JD wants to do a press release on this. Assuming she doesn't ask for testimonials, I think we just need to be sure that the document indicates where we have made decisions, where we have isuses, and where we need more input.
[15:48:50]
[15:49:05]
[15:49:28]
<Norm> ack norm
[15:49:29]
[15:49:30]
<Ian> NW: I think we should concentrate on what we need to do and let the press take care of itself.
[15:50:08]
<Ian> TBL: Publish arch doc with links to findings, and indicate clearly that this is a strawman.
[15:50:18]
<Ian> TB: If W3C thinks it's appropriate to do a press release, then I would support this.
[15:50:34]
<Ian> IJ: Objections to a press release?
[15:50:35]
<Ian> DC: Yes.
[15:51:24]
<Ian> q+
[15:51:25]
[15:51:30]
<Ian> q-
[15:51:31]
[15:51:49]
<Ian> TBL: If DC were to be absolved from press duty, would DC still object?
[15:51:50]
<Ian> DC: Yes.
[15:52:22]
<Ian> q+
[15:52:23]
[15:53:51]
<Ian> RF: I can't agree to a press release until I know what's in the document.
[15:54:08]
<Ian> (Both press release and arch document)
[15:54:54]
<Ian> TB: I agree with RF: if we agree based on document, and we agree to press release, seems ok to me.
[15:55:01]
<Ian> SW: So, for IJ report to Comm TEam:
[15:55:10]
<Ian> - In principle, agreement.
[15:55:19]
<Ian> - TAG wants to see where it is and to see press release text.
[15:55:27]
<Ian> --------------------------------
[15:55:38]
<Ian> Internet Media Type registration, consistency of use.
[15:55:43]
<Ian> * Action PC 2002/07/08: Propose alternative wording for finding regarding IANA registration. Refer to "How to Register a Media Type with IANA (for the IETF tree) "
[15:55:46]
<Ian> PC: No progress.
[15:55:58]
<Ian> -----------------
[15:56:02]
<Ian> # Qnames as identifiers
[15:56:10]
<Ian> 1. Action NW 2002/06/24: Follow up on Rick Jelliffe comments/proposal.
[15:57:17]
<Ian> NW: XPointer rejection almost dissolves the finding. Some specs require application-specific out-of-band mechanism, some do not.
[15:57:36]
<Ian> NW: I think the finding is useful for what it outlines, but I don't think we have ground to stand on.
[15:57:44]
[15:57:45]
[15:57:49]
<Ian> q-
[15:57:50]
[15:58:06]
<Ian> NW: XPath uses in-scope namespaces successfully.
[15:58:27]
<Ian> DC: But people don't expect to pull it out of a doc and use somewhere else. They do have that expectation for URIs and URI references.
[15:58:40]
<Ian> DC: The roles of URIs architecturally is to be context-free.
[15:59:09]
<Ian> NW: I'm suggesting that the finding has no recommendations to make. It has become even more just a bunch of red cones around a hole in the architecture. "Don't walk near here."
[15:59:12]
<Ian> DC: Fine.
[15:59:14]
<Ian> TB: Still useful.
[15:59:21]
<Ian> TBL: Yes, red cones are useful.
[15:59:27]
<Ian> NW: I will therefore republish with no recommendations.
[15:59:35]
<Ian> DC: Can you tell the story about the contrast?
[15:59:37]
<Ian> NW: Yes.
[15:59:44]
<Roy> [out on nature break -- back in a minute]
[16:00:30]
<Ian> TBL: What about special styling for stories?
[16:00:35]
<Ian> IJ: I don't think necessary. Just write well.
[16:00:42]
<Ian> DC: I think not useful for findings but for arch document, yes.
[16:01:07]
<Ian> NW: I will add material up front that this finding has no recommendations to make. Just identifies a nasty singularity in the space-time continuum.
[16:01:24]
<Ian> --------------------
[16:01:27]
<Ian> Consistency of Formatting Property Names, Values, and Semantics
[16:01:50]
<Ian> NW: I think that this one is done, too. I republished today. I think it's ok to state arch principles without saying how.
[16:01:58]
<Roy> [I'm back]
[16:02:09]
<Ian> NW: I did both of actions that CL requested.
[16:02:41]
<Ian> DC: I think we notify www-tag that we're done.
[16:03:17]
<Ian> IJ: What's the difference between saying one-week appeal and no appeal?
[16:05:50]
<Ian> DC: If you're reading this, and 7 days after publication, look around. If later than 7 days, then you are more certain that stable.
[16:05:59]
<Ian> IJ: Put this in status section then, not as critical for annoucnement to www-tag.
[16:06:04]
[16:06:05]
<TimBL> t-20
[16:06:08]
<Ian> -----------------------------------
[16:06:14]
<Ian> 1. httpRange-14: Need to make progress here to advance in Arch Document.
[16:07:10]
<Ian> DC: Principle of minimal constraint is on my side.
[16:07:30]
<TimBL> Your side being, "any?"
[16:08:03]
<Ian> RF: I've been talking about this on www-tag for last week, under heading resource and representation.
[16:08:12]
<TimBL> I though that I forced DanC into a contradiction starting from "Any".
[16:08:14]
<Ian> TB: I think RF's responses are dense and well-considered.
[16:08:28]
<TimBL> URI?
[16:08:37]
<Ian> DC: RF, so you conclude I can point to my car with an HTTP URI?
[16:08:39]
<Ian> RF: Yes.
[16:08:59]
<Ian> http://lists.w3.org/Archives/Public/www-tag/2002Jul/0178.html
[16:09:21]
<Ian> TB: Important to consider the consequences of the decision. Are there any meaningful consequences?
[16:09:45]
<Ian> DC: The irony is that, in principle, no, but there are some practical consequences.
[16:09:53]
<Ian> DC: I would recommend that people don't point HTTP URIs at their car.
[16:10:13]
<Norm> "Your gun, your bullet, your foot" -- that quotation is my favorite memory of a VM/CMS internals course I took once upon a time
[16:10:26]
<Ian> DC: I'm convinced that there are negative practical things to do in this area.
[16:11:01]
<Ian> TBL: I have in my mind a consistent model where HTTP URI points to a document about a car.
[16:11:16]
<Ian> TBL: I don't have a consistent system where HTTP URIs designate cars.
[16:11:35]
<Ian> TBL: The moment I retrieve something, it has something like a title. Therefore a work, not a car.
[16:11:55]
<Ian> TBL: The Dublin Core says that title is the title of the resource, not the representation.
[16:11:59]
<Stuart> q?
[16:12:00]
[16:12:31]
[16:12:33]
<TBray> q+
[16:12:34]
[16:12:54]
<Ian> DC: When people use HTTP URIs to point to a w3c tech report, they mean "title" of the resource, not the representation.
[16:13:15]
<Norm> q+
[16:13:16]
[16:13:19]
<Ian> DC: HTML doesn't have the ability to say 'this is the title of the resource you just referenced'. But RDF lets you do this.
[16:13:22]
<Ian> RF: Yes.
[16:13:56]
<Ian> TB: What would you change in the arch document?
[16:14:01]
<Ian> RF: What does it mean to do a POST?
[16:14:18]
<Stuart> q?
[16:14:19]
[16:14:20]
<Ian> RF repeats: A representation is not a resource.
[16:14:26]
<Stuart> ack DanC
[16:14:27]
[16:14:29]
<Ian> DC: You post to a car, not a car.
[16:14:32]
<Norm> q-
[16:14:34]
[16:14:34]
<Ian> RF: Yes, you can post to a car.
[16:14:38]
<DanC_> one posts a document to a resource
[16:14:53]
<DanC_> Ian, issue 15 came up in the arch doc drafting, yes?
[16:15:17]
<Ian> #
[16:15:17]
<Ian> # Whether two strings are different spellings for the same URI. [TAG issue URIEquivalence-15]
[16:15:28]
<Ian> (1.1)
[16:15:43]
<Norm> q+
[16:15:44]
[16:16:04]
<DanC_> TimBL, you're answering "where in the RDF specs does this matter?", not "where in the arch doc does this matter?"
[16:16:36]
<Ian> TBL: How affects the arch document - the table of properties of URI schemes.
[16:17:18]
<Stuart> ack TBray
[16:17:19]
[16:17:29]
<Norm> q-
[16:17:31]
[16:17:32]
<Stuart> ack Norm
[16:17:33]
[16:17:35]
<Ian> NW: I agree that this is a problem for RDF, but not Web architecture.
[16:18:06]
<Ian> TBL: If I can't build RDF on top of it, then the Web architecture is insufficient.
[16:18:26]
<Stuart> q?
[16:18:28]
[16:18:52]
<Ian> TBL: Show me the URI for a car.
[16:19:00]
<Ian> RF: I have URIs for robots in the MIT media lab.
[16:19:33]
<DanC_> my car: http://dm93.org/y2002/myCar-232
[16:20:04]
<Ian> TBL: You can say "this is a view of what robot sees" etc., but these are all Web pages. I have a problem with metadata - talking about the thing and the representation of the thing.
[16:20:33]
<Roy> content negotiation has same issue
[16:20:39]
<Ian> DC: HTTP last-modified means "last time web master updated the view of my car through HTTP"
[16:20:49]
[16:20:50]
<TBray> It seems like there is an important class distinction between resources which are in fact pieces of electronic information and those which are symbolic stand-ins for things like cars
[16:20:59]
<Ian> TBL: Layered world - properties that apply to car and to representation of car.
[16:21:17]
<TBray> it seems like RDF should be able to talk meaningfully about this distinction
[16:21:18]
<Ian> RF: there are some headers in HTTP that only refer to the representation. There are some fields that refer to the resource only (e.g., alternates).
[16:21:26]
<TimBL> s/Layered world/Youare now falling into the lcassic trap of the layered world/
[16:21:42]
<DanC_> Norm, no layered world.
[16:21:45]
<DanC_> s/norm/no/
[16:21:54]
<Ian> RF: You cannot say that the author of the file is the same as the author of a resource. You may have five authors of five representations that represent the same resoruce.
[16:22:07]
<Ian> RF: If RDF cannot support this, then RDF cannot support resources.
[16:22:30]
<Ian> DC: I think not an error in either. I think TimBL wishes he had an axiom on top of RDF but it's not there.
[16:22:46]
<TBray> unfortunately I have go ... bye
[16:22:46]
<Ian> TBL: Can I use FTP URI to point to a car?
[16:22:50]
<Zakim> -TBray
[16:22:55]
<-- TBray has quit (ChatZilla 0.8.7 [Mozilla rv:1.0.0/20020529])
[16:22:59]
<Ian> RF: HTTP is more powerful than FTP.
[16:23:11]
<Ian> DC: My position is independent of scheme; use any scheme you want to refer to my car.
[16:23:32]
<TimBL> Dan, I use <mailto:foo@foo.fog> to refer to your car.
[16:23:39]
<TimBL> Dan, I hereby use <mailto:foo@foo.fog> to refer to your car.
[16:23:45]
<Ian> DC: yes, presuming you own foo.fog
[16:23:49]
<DanC_> [I stipulate that TimBL owns foo.fog]
[16:24:10]
<Ian> TBL: Who owns foo@foo.fog?
[16:24:16]
<TimBL> Who owns <foo@foo.fog?>
[16:24:22]
<TimBL> Who owns <foo@foo.fog??
[16:24:26]
<TimBL> Who owns <foo@foo.fog?
[16:24:28]
<Ian> DC: I own the car.
[16:25:05]
<Ian> TBL: I think the Web rests on the assumption that mailto identifies a mailbox. The spec says so.
[16:25:39]
<Ian> TBL: I think it's useful to know that "mailto:" means someone is talking about a mailbox. And "ftp:" means someone talking about a file, and "http:" means someone talking about a document.
[16:26:33]
<Ian> t-
[16:26:34]
<Ian> 4
[16:27:04]
<Ian> DC: I think it's a handy heuristic that mailto: refers to mailboxes, but not critical to arch of Web.
[16:27:15]
<TimBL> "HOLD THAT THOUGHT"
[16:28:08]
<Zakim> -Paul
[16:28:12]
<Zakim> -TimBL
[16:28:17]
<Ian> Adjourned