Time stamps are EDT
<Ian> Scribe: IJ
<Ian> Roll: All present but CL
<TimBL> RRSAgent, pointer?
<RRSAgent> See http://www.w3.org/2002/07/08-tagmem-irc#T20-29-54
<Ian> Agenda comments?
<Ian> Regrets next week? None
<Ian> Next meeting 22 July
<Ian> SW: DO, last week, group said it would not have quorum rules.
<TBray> intermittent dull roar in background
<DanC_> order? is somebody suggesting the record is inaccurate?
<DanC_> this seems like an agenda request, not a fix of the minutes.
<Ian> ack DanC
<Zakim> DanC, you wanted to make a point of order
<Ian> Accept minutes from last week?
<Ian> SW: Accepted.
<DanC_> hmm... perhaps review of minutes should go before review of agenda.
<Ian> Action 1. IJ: Find out whether the W3C Comm Team expects to have a publishing moratorium in August.
<Ian> IJ: No moratorium
<Ian> (Learned this morning)
<Ian> Arch document
<Ian> 1. ACTION TBL 2002/05/05: Negotiate more of IJ time for arch doc
<TBray> seems like we have a dull roar whenever Stuart's not talking
<Ian> TBL: I would like to keep this on the back burner (for 30 days).
<Ian> TBL: I think we've made the point, but in the fall, a few things happen.
<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.
<TBray> plus Ian's on vacation 2nd half of August
<Ian> DC: I would rather process doc go to sleep for 2 months than TAG.
<Ian> DC: Please push this at AB ftf meeting.
<Ian> 2. ACTION RF 2002/06/24: Write a paragraph on technical and political aspects of URIs and URI References.
<Ian> RF: I touched on this on mailing list, but this para is 2nd priority to the URI spec itself.
<Ian> Is this on critical path for moving arch document forward?
<Ian> RF: I hope not.
<Ian> 3. Action TB, DC 2002/07/08: Propose text for section 1.1 (URI Schemes)
<Ian> TB: Done.
<Ian> 4. Action CL 2002/07/08: Propose text for section 2 (Formats). Deadline 30 July. [Not done]
<Ian> IJ: I have started incorporating TB text.
<Ian> TB: I am beginning to question whether it's worthwhile talking about varying properties of URIs.
<Ian> IJ: I have put SW's table in arch doc appendix for now.
<Ian> TBL: The important arch point is that these properties vary.
<Ian> DC: I disagree with the way the table answers the question.
<Ian> TBL: Disagreeing with column names or cell contents?
<Ian> DC: I disagree with TBL's conclusion that http points to document.
<Ian> TBL: My opinion is that you can't put "any" there since there's an open issue.
<Ian> TB: I think this belongs in an appendix.
<Ian> SW: I'm fine with people disagreeing on the contents of the table (for now)
<Ian> TBL: "Decentralized" is a bit of a political thing...
<Ian> DC: Quite.
<Ian> TBL: Subject to ongoing discussion as to the contents, I think the table is a useful thing.
<Ian> TBL: I'd like to generate table from RDF.
<Ian> Action DC: Regenerate this table from RDF (looking closely at contents of cells).
<Ian> ack TBray
<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.
<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.
<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.
<Ian> ack TimBL
<Ian> TBL: I think this is as normative as the rest of the document.
<Ian> TBL: We should say you shouldn't re-invent the while.
<DanC_> (actually, you don't have uuid, timbl; it's not registered. Er..hmm... maybe it is, under urn:_
<Ian> TBL: If you are proposing a new URI scheme that has properties of scheme s, then use s.
<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?
<Ian> TBL: Yes, also to raise attention about some schemes.
<Ian> TB: Ok, that sounds plausible to me.
<Ian> IJ: I was going to suggest leaving in an appendix for now, and deciding later whether to pull out.
<Ian> IJ: Good to have clarification on the meaning of the columns.
<DanC_> [note to self, for ation: a possible corrollary of table with props: if you want an admin hierarchy, use DNS.]
<Ian> TB: "Resource state dynamics"?
<Ian> TBL: Is this just persistence?
<DanC_> [note to self: "fixed content resource"? column]
<Ian> TBL: Column heads: Persistence and Dereferenceability
<Ian> IJ: What values would one find for each column (where possible to enumerate)?
<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]
<Ian> TB: What about text I submitted?
<Ian> DC: I disagree on the first sentence.
<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.
<Ian> DC: Varies by more than time.
<Ian> TB: Why is time specially distinguished?
<Ian> RF: People keep forgetting it.
<TimBL> time, language, representation, ....
<Ian> DC: Not sure if I definitely object.
<Ian> PC: If DC's concern is that people forget that is to put in a second sentence.
<DanC_> my www9 presentation on this mapping between URIs and content: http://www.w3.org/2000/Talks/www9-larch/all.htm
<Ian> TBL: I'd like parameters to be tabulated.
<TimBL> Table head: What can resoirce vary under?
<Ian> TB: I think DC's objection is correct.
<Ian> TB: Leans to heavily on time.
<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 ...."
<Ian> Action TB: Clarify first sentence.
<DanC_> -> http://www.textuality.com/tag/s1.1.html
<Ian> DC: A lot of naming issues are justified architecturally by economics. E.g., costly to deploy new URI schemes ubiquitously.
<Ian> TB: My text says that.
<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.
<Ian> DC: Used to be the case that you have to go through several machines (susie!bob!ian...) to get to ian.
<TBray> aaah... watmath!decvax!anywhere as I recall...
<Ian> TBL: Root emerged. The Web tree-ified.
<Ian> DC: The point is that URIs serve this need in communication (to refer to things).
<Ian> TBL: DC explaining why it's useful to have absolute names - why URis mean the same thing wherever you are.
<Ian> s/URIs/absolute URIs/
<Ian> TB: Principle - "Absolute addressing is better than context-sensitive addressing."
<Ian> DC: More subtle than that - cheaper....
<TimBL> Zakim, temporarily mute PaulC
<Zakim> sorry, TimBL, I do not see a party named 'PaulC'
<Norm> The ability to provide absolute addressing is better...
<Ian> DC: This is the adopted principle - that is the way it is.
<TimBL> Zakim, who is here?
<Zakim> On the phone I see TimBL, Stuart, Norm, DanC, Ian, TBray, DOrchard, Roy, Paul
<Zakim> On IRC I see DaveO, TBray, Zakim, Roy, Stuart, DanC_, Norm, Ian, RRSAgent, TimBL
<TimBL> Zakim, temporarily mute Paul
<Zakim> Paul should now be muted
<Ian> Action SW: WRite down this arch principle.
<Ian> zakim, unmute paul
<Zakim> Paul should no longer be muted
<Zakim> Paul should now be unmuted again
<TBray> Paul came back but the name didn't
<TBray> er the noise not the name
<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?
<Ian> DC: Yes, there is a subtlety here.
<Ian> DC: There is a tension.
<Ian> TBL: DNS as weakness in Web.
<TBray> zakim, mute TBray
<Zakim> TBray should now be muted
<TBray> zakim, unmute TBray
<Zakim> TBray should no longer be muted
<Ian> PC: We all decided that DNS was better.
<Ian> SW: If you are going to assert that DNS is a weak point, would you be bound to propose a substitute?
<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.
<Ian> DC: TBL, you have to write the story, not just expect people to buy it.
<TBray> for the record, is there any way to improve the audio quality? I'm getting a headache
<Ian> DC: In progress; awaiting a reply.
<Ian> TB: What's going on here: different answers from Mark Baker, Keith Moore, Michael Mealing?
<Ian> DC: Sometimes hard to get answer from IETF.
<DanC_> gold star for Bray providing text for 1.1, btw.
<Ian> TB: How do we get from here to first public WD 15 August?
<Ian> DC: I'm happy to have IJ chew on text until early August and then ship it.
<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
<Ian> DC: I have no lower bound on quality.
<Ian> ack DanC_
<Ian> ack DanC
<Ian> TB: I do have a lower bound on quality.
<Ian> IJ: Today at Comm Team talked about press release for first public WD.
<Ian> DC: No thank you.
<Ian> DO: I agree with DC.
<Ian> PC: I agree with DC.
<TimBL> I also agree with DC
<Ian> IJ: I told Janet document would be rough.
<Ian> TB: You could achieve higher quality by removing partial sections.
<Ian> DC: You make it sound like shorter is easier, but that's not my experienc3.
<Ian> SW: Where would we have to be to have something that would make Janet happy.
<Ian> TB: If we do something that has WD on the top, it will get press coverage anyway.
<Ian> DC: If we do a press release, I'll have to take press calls.
<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.
<Norm> ack norm
<Ian> NW: I think we should concentrate on what we need to do and let the press take care of itself.
<Ian> TBL: Publish arch doc with links to findings, and indicate clearly that this is a strawman.
<Ian> TB: If W3C thinks it's appropriate to do a press release, then I would support this.
<Ian> IJ: Objections to a press release?
<Ian> DC: Yes.
<Ian> TBL: If DC were to be absolved from press duty, would DC still object?
<Ian> DC: Yes.
<Ian> RF: I can't agree to a press release until I know what's in the document.
<Ian> (Both press release and arch document)
<Ian> TB: I agree with RF: if we agree based on document, and we agree to press release, seems ok to me.
<Ian> SW: So, for IJ report to Comm TEam:
<Ian> - In principle, agreement.
<Ian> - TAG wants to see where it is and to see press release text.
<Ian> Internet Media Type registration, consistency of use.
<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) "
<Ian> PC: No progress.
<Ian> # Qnames as identifiers
<Ian> 1. Action NW 2002/06/24: Follow up on Rick Jelliffe comments/proposal.
<Ian> NW: XPointer rejection almost dissolves the finding. Some specs require application-specific out-of-band mechanism, some do not.
<Ian> NW: I think the finding is useful for what it outlines, but I don't think we have ground to stand on.
<Ian> NW: XPath uses in-scope namespaces successfully.
<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.
<Ian> DC: The roles of URIs architecturally is to be context-free.
<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."
<Ian> DC: Fine.
<Ian> TB: Still useful.
<Ian> TBL: Yes, red cones are useful.
<Ian> NW: I will therefore republish with no recommendations.
<Ian> DC: Can you tell the story about the contrast?
<Ian> NW: Yes.
<Roy> [out on nature break -- back in a minute]
<Ian> TBL: What about special styling for stories?
<Ian> IJ: I don't think necessary. Just write well.
<Ian> DC: I think not useful for findings but for arch document, yes.
<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.
<Ian> Consistency of Formatting Property Names, Values, and Semantics
<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.
<Roy> [I'm back]
<Ian> NW: I did both of actions that CL requested.
<Ian> DC: I think we notify www-tag that we're done.
<Ian> IJ: What's the difference between saying one-week appeal and no appeal?
<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.
<Ian> IJ: Put this in status section then, not as critical for annoucnement to www-tag.
<Ian> 1. httpRange-14: Need to make progress here to advance in Arch Document.
<Ian> DC: Principle of minimal constraint is on my side.
<TimBL> Your side being, "any?"
<Ian> RF: I've been talking about this on www-tag for last week, under heading resource and representation.
<TimBL> I though that I forced DanC into a contradiction starting from "Any".
<Ian> TB: I think RF's responses are dense and well-considered.
<Ian> DC: RF, so you conclude I can point to my car with an HTTP URI?
<Ian> RF: Yes.
<Ian> TB: Important to consider the consequences of the decision. Are there any meaningful consequences?
<Ian> DC: The irony is that, in principle, no, but there are some practical consequences.
<Ian> DC: I would recommend that people don't point HTTP URIs at their car.
<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
<Ian> DC: I'm convinced that there are negative practical things to do in this area.
<Ian> TBL: I have in my mind a consistent model where HTTP URI points to a document about a car.
<Ian> TBL: I don't have a consistent system where HTTP URIs designate cars.
<Ian> TBL: The moment I retrieve something, it has something like a title. Therefore a work, not a car.
<Ian> TBL: The Dublin Core says that title is the title of the resource, not the representation.
<Ian> DC: When people use HTTP URIs to point to a w3c tech report, they mean "title" of the resource, not the representation.
<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.
<Ian> RF: Yes.
<Ian> TB: What would you change in the arch document?
<Ian> RF: What does it mean to do a POST?
<Ian> RF repeats: A representation is not a resource.
<Stuart> ack DanC
<Ian> DC: You post to a car, not a car.
<Ian> RF: Yes, you can post to a car.
<DanC_> one posts a document to a resource
<DanC_> Ian, issue 15 came up in the arch doc drafting, yes?
<Ian> # Whether two strings are different spellings for the same URI. [TAG issue URIEquivalence-15]
<DanC_> TimBL, you're answering "where in the RDF specs does this matter?", not "where in the arch doc does this matter?"
<Ian> TBL: How affects the arch document - the table of properties of URI schemes.
<Stuart> ack TBray
<Stuart> ack Norm
<Ian> NW: I agree that this is a problem for RDF, but not Web architecture.
<Ian> TBL: If I can't build RDF on top of it, then the Web architecture is insufficient.
<Ian> TBL: Show me the URI for a car.
<Ian> RF: I have URIs for robots in the MIT media lab.
<DanC_> my car: http://dm93.org/y2002/myCar-232
<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.
<Roy> content negotiation has same issue
<Ian> DC: HTTP last-modified means "last time web master updated the view of my car through HTTP"
<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
<Ian> TBL: Layered world - properties that apply to car and to representation of car.
<TBray> it seems like RDF should be able to talk meaningfully about this distinction
<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).
<TimBL> s/Layered world/Youare now falling into the lcassic trap of the layered world/
<DanC_> Norm, no layered world.
<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.
<Ian> RF: If RDF cannot support this, then RDF cannot support resources.
<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.
<TBray> unfortunately I have go ... bye
<Ian> TBL: Can I use FTP URI to point to a car?
<-- TBray has quit (ChatZilla 0.8.7 [Mozilla rv:1.0.0/20020529])
<Ian> RF: HTTP is more powerful than FTP.
<Ian> DC: My position is independent of scheme; use any scheme you want to refer to my car.
<TimBL> Dan, I use <mailto:email@example.com> to refer to your car.
<TimBL> Dan, I hereby use <mailto:firstname.lastname@example.org> to refer to your car.
<Ian> DC: yes, presuming you own foo.fog
<DanC_> [I stipulate that TimBL owns foo.fog]
<Ian> TBL: Who owns email@example.com?
<TimBL> Who owns <firstname.lastname@example.org?>
<TimBL> Who owns <email@example.com??
<TimBL> Who owns <firstname.lastname@example.org?
<Ian> DC: I own the car.
<Ian> TBL: I think the Web rests on the assumption that mailto identifies a mailbox. The spec says so.
<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.
<Ian> DC: I think it's a handy heuristic that mailto: refers to mailboxes, but not critical to arch of Web.
<TimBL> "HOLD THAT THOUGHT"