IRC log of TAG teleconf 15 July 2002

Time stamps are EDT

<Ian> Scribe: IJ

<Ian> Roll: All present but CL

<TimBL> RRSAgent, pointer?

<RRSAgent> See

<Ian> Agenda comments?

* DanC_ hears background white noise

<Ian> Regrets next week? None

* TimBL .... (Paul's projector melts)

<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.

* DanC_ q+ to make a point of order

* Zakim sees DanC on the speaker queue

<Ian> ....Stuart...

<Ian> ack DanC

<Zakim> DanC, you wanted to make a point of order

* Zakim sees no one on the speaker queue

<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> ----------

<Ian> Arch document

* Norm thinks that must be record time for Administrivia

* TimBL has emailed comments on minutes - not on accuracy but on discussion.

<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.

<Stuart> q?

* Zakim sees no one on the speaker queue

<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.

<Norm> 1

<Norm> +1

* Zakim wonders where 1 is

<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 (previous comment TB)

<Ian> RF: I hope not.

* DanC_ suddenly wants a 2002/06/24 link to go look at the context of Roy's action

<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.

<TBray> q+

* Zakim sees TBray on the speaker queue

<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).

<TBray> q?

* Zakim sees TBray on the speaker queue

<Ian> ack TBray

* Zakim sees no one on the speaker queue

<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.

<TimBL> q+

* Zakim sees TimBL on the speaker queue

<Ian> q+

* Zakim sees TimBL, Ian on the speaker queue

<Ian> ack TimBL

* Zakim sees Ian on the speaker queue

<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:_

<DanC_> )

<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?

* DanC_ q+

* Zakim sees Ian, DanC on the speaker queue

<Ian> TBL: Yes, also to raise attention about some schemes.

<Ian> TB: Ok, that sounds plausible to me.

* DanC_ q-

* Zakim sees Ian on the speaker queue

<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?

* TimBL hears background noise

<Ian> DC: I disagree on the first sentence.

* TimBL hears background noise in the speaking breaks

<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> "


<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.

<Stuart> q?

* Zakim sees Ian on the speaker queue

<Ian> q-

<DanC_> my www9 presentation on this mapping between URIs and content:

* Zakim sees no one on the speaker queue

<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_> ->

<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

* TimBL concludes noise is not paul

<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 notes: # Action DC 2002/07/08: Ask Michael Mealing when IETF decided not to use HTTP URis to name protocols. Done.

<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.

* DanC_ q+

* Zakim sees DanC on the speaker queue

<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> q+

* Zakim sees DanC, Ian on the speaker queue

<Ian> DC: I have no lower bound on quality.

<Ian> ack DanC_

* Zakim sees DanC, Ian on the speaker queue

<Ian> ack DanC

* Zakim sees Ian on the speaker queue

<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

<Stuart> +1

* Zakim wonders where 1 is

<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> q?

* Zakim sees Ian on the speaker queue

<Ian> q-

* Zakim sees no one on the speaker queue

<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.

<Norm> q+

<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.

* Zakim sees Norm on the speaker queue

* DanC_ struggles to accept the role of the press in his work; may just never get it thru his head.

<Norm> ack norm

* Zakim sees no one on the speaker queue

<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> q+

* Zakim sees Ian on the speaker queue

<Ian> q-

* Zakim sees no one on the speaker queue

<Ian> TBL: If DC were to be absolved from press duty, would DC still object?

<Ian> DC: Yes.

<Ian> q+

* Zakim sees Ian on the speaker queue

<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> --------------------------------

<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> -----------------

<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.

* DanC_ q+

* Zakim sees Ian, DanC on the speaker queue

<Ian> q-

* Zakim sees DanC on the speaker queue

<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> --------------------

<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.

* Norm notes that Ian's request is a stylesheet issue with rather broad implications

<TimBL> t-20

<Ian> -----------------------------------

<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.

<TimBL> URI?

<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.

<Stuart> q?

* Zakim sees DanC on the speaker queue

* Ian missed RF comment about whether Dublin Core was referring to representation or resource.

<TBray> q+

* Zakim sees DanC, TBray on the speaker queue

<Ian> DC: When people use HTTP URIs to point to a w3c tech report, they mean "title" of the resource, not the representation.

<Norm> q+

* Zakim sees DanC, TBray, Norm on the speaker queue

<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?

<Stuart> q?

* Zakim sees DanC, TBray, Norm on the speaker queue

<Ian> RF repeats: A representation is not a resource.

<Stuart> ack DanC

* Zakim sees TBray, Norm on the speaker queue

<Ian> DC: You post to a car, not a car.

<Norm> q-

* Zakim sees TBray on the speaker queue

<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> #

<Ian> # Whether two strings are different spellings for the same URI. [TAG issue URIEquivalence-15]

<Ian> (1.1)

<Norm> q+

* Zakim sees TBray, Norm on the speaker queue

<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

* Zakim sees Norm on the speaker queue

<Norm> q-

* Zakim sees no one on the speaker queue

<Stuart> ack Norm

* Zakim sees no one on the speaker queue

<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.

<Stuart> q?

* Zakim sees no one on the speaker queue

<Ian> TBL: Show me the URI for a car.

<Ian> RF: I have URIs for robots in the MIT media lab.

<DanC_> my car:

<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"

* Norm scratches his head

<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.

<DanC_> s/norm/no/

<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?

<Zakim> -TBray

<-- 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:foo@foo.fog> to refer to your car.

<TimBL> Dan, I hereby use <mailto:foo@foo.fog> 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 foo@foo.fog?

<TimBL> Who owns <foo@foo.fog?>

<TimBL> Who owns <foo@foo.fog??

<TimBL> Who owns <foo@foo.fog?

<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> t-

<Ian> 4

<Ian> DC: I think it's a handy heuristic that mailto: refers to mailboxes, but not critical to arch of Web.


<Zakim> -Paul

<Zakim> -TimBL

<Ian> Adjourned