IRC log of tagmem on 2002-07-22

Timestamps are in UTC.

19:13:50 [RRSAgent]
RRSAgent has joined #tagmem
19:14:03 [Ian]
19:14:10 [Ian]
FTF meeting in Vancouver.
19:14:26 [Ian]
Action TB: Send information about hotels and other options for meeting.
19:14:33 [Ian]
19:15:19 [Ian]
New issues:
19:15:23 [Ian]
1. Bad practice: Overriding HTTP content-type with a URI reference.See email from TBL.
19:16:41 [Ian]
Resolved: Accepted as issue contentTypeOverride-24
19:17:04 [Ian]
2. "Deep linking illegal" bad practice? See email from Tim Bray.
19:17:11 [Ian]
Email from TB:
19:17:19 [DanC]
fyi, Links and Law: Myths
19:18:07 [Stuart]
19:18:41 [Ian]
DC: I am nervous about scope...but no objection to accepting this as an issue.
19:19:24 [Ian]
RF: I support that in general that there is nothing to prevent deep linking on the net. But the way copyright works, if you are using someone's content in a way that denies them business value, you're screwed anyway.
19:20:29 [Ian]
TB: Way to do this is to use an authentication scheme, or use referrer field. They didn't do any of this. If they had done that and the bad guys had worked around this, then they would have had grounds to take them to court.
19:20:53 [Ian]
RF: I agree with you in principle. But the ruling in this case was about one news org taking content from another.
19:21:47 [Ian]
Action PC: Ask Henrik Frystyk Nielsen to provide us with a precis of the ruling.
19:22:32 [Ian]
PC: We should tell people that if they publish a URI and don't want someone to get at it, what they can do.
19:22:59 [Ian]
TB: There has been litigation about this several times. I think this will keep coming up.
19:23:04 [Roy]
19:23:08 [Ian]
RF: I agree with the principle in general. I am worried about the actual facts of the case.
19:23:35 [DanC]
following the "if it jams, force it; if it breaks, it needed replacing anyway" principle, let's do make this an issue. i.e. better to ask forgiveness than permission.
19:23:51 [Ian]
Resolved: Accept this as issue deepLinking-25.
19:23:51 [DanC]
1/2 ;-)
19:24:00 [Ian]
19:24:01 [Ian]
Arch doc
19:24:48 [DanC]
Ian: I was relieved of some AB admin duties. (e.g. meeting summaries)
19:25:00 [Ian]
IJ: Steve Ziles picking up some of my duties.
19:25:04 [DanC]
... also, as of 1Aug, my writing assignment there should go on hold.
19:25:14 [DaveO]
19:25:47 [Ian]
Refined comment: 1 Aug I will give new draft to AB (if not sooner). Then I will focus on arch doc.
19:25:59 [Ian]
CLOSED TBL 2002/05/05: Negotiate more of IJ time for arch doc
19:26:10 [Ian]
ACTION RF 2002/06/24: Write a paragraph on technical and political aspects of URIs and URI References.
19:26:49 [DanC]
pointer to what you've already written?
19:26:51 [Ian]
RF: I sent content across several emails. I could summarize that content.
19:27:21 [Ian]
RF: I will send to TAG today.
19:27:27 [Ian]
# Action DC 2002/07/08: Propose text for section 1.1 (URI Schemes)
19:27:29 [DanC]
re my action, I'm about 2/3rds of the way thru:
19:28:12 [Ian]
DC: I started working on table. Idea was to take column headings. I couldn't find any column headings that generalized to whole URI schemes.
19:28:29 [Ian]
I did write a FAQ:
19:28:43 [Ian]
DC: Some progress.
19:29:57 [Ian]
TB: I have revised my comments. See edits from SW:
19:30:07 [DanC]
"save early. save often"
19:30:56 [Ian]
TB: I think SW's and CF's points are good ones.
19:31:02 [Stuart]
19:31:22 [Ian]
# Action DC: 2002/07/15: Generate tables of URI scheme props from RDF. (Progress)
19:31:54 [Ian]
# Action DC 2002/07/08: Ask Michael Mealing when IETF decided not to use HTTP URis to name protocols. Awaiting reply.
19:31:59 [Ian]
DC: I need to get more from MM.
19:32:37 [Ian]
DC: Harder to find out "what's going on there". I am not willing to do intelligence on the whole IETF.
19:33:08 [Ian]
TB: There is some perception that the IETF will not be using http URIs for namespaces as a matter of policy. We need to find out if that's the case (and if so, we are likely to disagree).
19:33:33 [Ian]
DC: No way to get a clear answer unless policy part of an RFC.
19:33:45 [Ian]
RF: We can ask the IESG a question about what drafts they are rejecting.
19:33:52 [Ian]
DC: Do they *owe* me an answer?
19:33:56 [Ian]
RF: Don't know.
19:34:07 [Ian]
DC: I can try. But last time I put something on their agenda, it took them 9 months to answer.
19:34:52 [Ian]
Resolved: change action from ask Michael Mealing to ask the IESG. Change to "if and when" IETF decided...
19:35:04 [Ian]
DC: As for action about the table of URI schemes, I find not useful.
19:35:21 [Ian]
DC: I hope the table is not in the arch doc. I find it to be extremely misleading.
19:35:56 [Ian]
- Relative URI column is misleading. It's supported syntactically for all schemes.
19:36:07 [Ian]
RF: URN scheme doesn't allow "/" for hierarchy.
19:36:17 [Ian]
DC: But if there's a slash in there, then there's hierarchy.
19:36:27 [Ian]
SW: Is there hierarchy to mailto?
19:36:52 [Ian]
RF: Find the useful bit and put into the table.
19:36:56 [Ian]
DC: I tried and was unable.
19:37:23 [Ian]
DC: Maybe a way to rephrase the relative URi column to be useful.
19:37:38 [Ian]
DC: For spelling equivalence, if you want to be sure - spell the same way.
19:37:46 [Ian]
DC: I couldn't make sense of functional equivalence at all.
19:37:52 [Ian]
DC: For admin, I couldn't find pattern.
19:38:06 [Ian]
RF: I liked that because it pointed out that there was no diff between DNS authority and URN authority.
19:38:17 [Ian]
DC: That's a point worth making, but the table doesn't make it.
19:38:43 [Ian]
(The differences between URNs and DNS are not interesting, but the table doesn't convey that.)
19:39:14 [Ian]
RF: Can we play with the RDF?
19:39:15 [Ian]
DC: Yes.
19:40:30 [Ian]
TB: The purpose of the table was not to be exhaustive, but to cover a few characteristics of deployed schemes as active discouragement to reinvent the wheel.
19:40:44 [Ian]
TB: Something modest and hand-prepared would probably do the job.
19:41:02 [DanC]
19:41:22 [DanC]
"each valid use of a URI reference unambiguously identifies one resource
19:41:23 [DanC]
19:41:29 [Ian]
19:41:41 [Ian]
19:41:44 [Ian]
19:43:09 [Ian]
From Norm:
19:43:11 [Ian]
Definition: a URI identifies a resource that is amenable to
19:43:11 [Ian]
unambiguous interpretation by recursive application of a finite set of
19:43:11 [Ian]
specifications, beginning with the specification that governs the
19:43:11 [Ian]
scheme of the URI.
19:43:15 [Ian]
19:44:12 [DanC]
not clear that we're saying the same thing.
19:44:23 [Ian]
I think we should try to align there.
19:44:29 [Ian]
# Action SW 2002/07/15: Draft text for arch principle on absolute addressing preferred over context-sensitive addressing.
19:44:44 [Ian]
19:45:46 [Ian]
TB: I think SW's draft is solid. Some feedback on www-tag.
19:46:29 [Ian]
SW: I will include the bang-style addressing (email) in the rationale.
19:46:48 [Ian]
DC: "Does the Web use local or global naming?"
19:47:04 [Ian]
TB: I'm not sure that the anecdote adds much to the discussion.
19:47:15 [Ian]
DC: Global naming scales better in certain ways (generic principle).
19:47:31 [Ian]
DC: I think the principle applies to absolute URI refs (but not "../foo").
19:48:07 [Ian]
RF: NEWS URIs are context dependent.
19:48:36 [Ian]
RF: You have to phrase this in a way that says that it's ok to refer to a context-dependent resource if the resource is meant to be context-dependent.
19:49:02 [Ian]
RF: E.g., reference to a newsgroup that is relative to your local access point.
19:49:09 [Ian]
RF: Whereas nntp: is a global context.
19:49:12 [Ian]
RF: The details get nasty.
19:49:42 [Ian]
RF: You need to identify what you mean by resource first, then say whether the resource needs to be globally consistent ("sameness" must be global).
19:50:17 [Ian]
RF: When we insert this text in the arch doc, we need to be concerned about the nasty details.
19:50:28 [Ian]
RF: I suggest not to say "resource or concept", just "resource".
19:51:50 [DanC]
does 30Aug still look likely?
19:52:12 [DanC]
ah; I was thinking that sayid 30Jul
19:52:49 [Ian]
19:52:52 [Ian]
# Internet Media Type registration, consistency of use.
19:52:52 [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) "
19:53:02 [Ian]
PC: Not done.
19:54:13 [Ian]
PC: I hope to have done this week.
19:54:23 [Ian]
19:54:24 [Ian]
# Qnames as identifiers:
19:54:24 [Ian]
* Action NW 2002/07/15: Republish finding. What is status of this? Can we close qnameAsId-18?
19:54:33 [Ian]
4. Formatting properties:
19:54:33 [Ian]
* What is status of issue formattingProperties-19?
19:54:35 [Ian]
Both done.
19:54:50 [Ian]
Action IJ: Update status sections to indicate that these are approved findings.
19:54:59 [Zakim]
19:55:10 [Ian]
zakim, ??P5 is David
19:55:11 [Zakim]
+David; got it
19:55:43 [Ian]
19:55:51 [Ian]
1. httpRange-14: Need to make progress here to advance in Arch Document. See thread started by Tim Bray
19:56:26 [Ian]
DC: Stalement. Two rational arguments.
19:56:38 [Ian]
TBL: If TBL confirms NW's writings,
19:56:42 [Ian]
then I have a simple answer.
19:56:50 [Ian]
19:57:38 [Ian]
RF: My answer is that this conflates the URI with the method. When you perform a GET, you get back a document. But you don't define the resource type using the method.
19:58:27 [Ian]
RF: If we define URIs in terms of what they are when you do a GET, then yes, HTTP URIs refer to documents. But we don't define URIs that way.
19:58:37 [Stuart]
19:58:48 [Ian]
TB: I thought there was material talk on the list about the workings of RDF.
19:59:07 [Ian]
TB: RDF should be able to talk about resources and representations of resources. If it can't, it's broken.
19:59:49 [Ian]
DC: I can try to take TBL's place for a minute. He wants to conclude that "http: => document" and wants to ensure that those are disjoint from people and cars.
20:00:21 [Ian]
RF: If the definition is not consistent across all methods, then the definition is wrong.
20:00:58 [Ian]
SW: When TBL talks of "docs" he's talking about document resources (not representations).
20:01:07 [Ian]
SW: And RF is referring to representations.
20:01:53 [Norm]
20:02:48 [Ian]
RF: Yes, I know that TBL is using that as a basis point. But it still doesn't work - there are still HTTP resources on the Web that are not remotely documents.
20:02:48 [Ian]
RF: The distinction TBL wants to make falls over in practice.
20:02:50 [Ian]
DC: I'd like a term that means "bits + mime type" (other than representation)....
20:02:52 [Ian]
RF: We chose "entity body" since we couldn't come up with a better term...
20:03:10 [Ian]
DC: I refer to bits + mime type as a document. And resources that act like documents, I call "works"
20:03:43 [Ian]
TB: There does seem to be a meaningful distinction between a think that's basically its representation, and more abstract things like a weather report.
20:03:46 [Norm]
Stuart: are you using the queue?
20:04:03 [Stuart]
20:04:06 [TBray]
20:04:33 [Norm]
ack norm
20:04:38 [TBray]
20:04:42 [Ian]
SW: How to make progress on this?
20:04:58 [Ian]
DC: I'm willing to try to convince TBL.
20:05:05 [tim-mtg]
tim-mtg has joined #tagmem
20:05:26 [Ian]
TB: we need language for this (about what an HTTP resource is...)
20:05:56 [Ian]
Tim, people are asking what breaks if the TAG doesn't follow your path.
20:06:03 [tim-mtg]
According to my philosophy?
20:06:17 [Norm]
wrt range of HTTP
20:06:28 [Ian]
TB: I suggest procedurally that we ask TimBL to react to proposed text and www-tag comments and help us make progress on this issue.
20:06:38 [tim-mtg]
I'm not sure that I can do this in IRC.
20:06:44 [Ian]
[Proposed text from Dan's FAQ or Norm's text.]
20:07:01 [TBray]
indeed, but don't worry, we're giving you action items to sort it out :)
20:07:11 [tim-mtg]
It is possible to have a system in which the publicher of a URI cetermines what it actually idenifies 9car opr web page) but all the systems like
20:07:29 [tim-mtg]
dubloin code which assume blithley that a wbe page is idenified by its URI have to be put on hold
20:07:34 [Ian]
Action SW: Persuade TimBL to write an exposition of his position.
20:08:02 [tim-mtg]
until they can check with the publichers of the URI to find out whether in fact the URI identifies something which is nota web page.
20:08:36 [Ian]
20:08:37 [Ian]
# uriMediaType-9: Status of negotiation with IETF? See message from DanC.
20:08:37 [Ian]
* Action TBL: Get a reply from the IETF on the TAG finding.
20:08:47 [TBray]
20:09:03 [Ian]
DC: TimBL proposed this for June IETF/W3C meeting. Didn't get far then.
20:09:09 [Ian]
DC: We are next meeting 12 November.
20:09:48 [Roy]
[out for a minute]
20:11:56 [Ian]
SW: I'm not sure what our best course of action is here.
20:12:07 [Roy]
20:12:21 [Ian]
SW: Either a mid-November backstop or a possible forum (W3C CG) before then.
20:12:31 [Ian]
SW: Do we need to be more active than that?
20:12:37 [Ian]
DC: I'm at a loss.
20:12:52 [Ian]
SW: Then I propose that we try to get on agenda of CG first, or next IETF/W3C meeting otherwise.
20:12:57 [Ian]
20:13:14 [Ian]
20:13:14 [Ian]
20:13:14 [Ian]
# RFC3023Charset-21:
20:13:14 [Ian]
* Action CL: Send copy of information sent to tag regarding RFC3023Charset-21 to www-tag.
20:13:58 [Ian]
20:14:42 [Stuart]
20:14:45 [Ian]
20:14:55 [Ian]
# Status of URIEquivalence-15. Relation to Character Model of the Web (chapter 4)? See text from TimBL on URI canonicalization and email from Martin in particular.
20:14:58 [Ian]
TB: This is serious.
20:15:12 [Ian]
TB: Martin seems to be saying "deal with it"
20:15:30 [Ian]
DC: Two reasons:
20:16:11 [Ian]
a) The only way you can be sure that a consumer will notice that you mean the same thing is that you've spelled it the same way. I think that they're not wrong. Nothing wrong with string compare.
20:16:26 [Ian]
In general, it's an art to gather that something spelled differently means the same thing.
20:16:45 [DaveO]
20:16:57 [Ian]
TB: If we believe that, should there be a recommendation that "when you do this, only %-escape when you have to, and use lowercase letters." Where should that be written?
20:17:04 [Ian]
DC: Shortest path to target is the I18N WG.
20:17:05 [Stuart]
ack DanC
20:17:07 [Zakim]
DanC, you wanted to disagree that it's wrong
20:17:32 [Ian]
DC: RFC 2396 applies equally to all URI schemes.
20:18:01 [DanC]
generating absolute from relative URI is not scheme-specific.
20:18:01 [Ian]
DO: There are absolutization scheme(s) and things like scheme-specific rules (e.g., generating an absolute) and we should take this into account when we talk about doing a string compare.
20:18:09 [Ian]
RF: Different issues here.
20:18:58 [Ian]
RF: There is a syntax mechanism to go from rel URI to abs URI. But no scheme-specific semantics on that. There are scheme-specific fields (e.g,. host name) that have equivalence rules. It boils down to this: the most efficient way to deal with these cases is to require a canonical form and compare by bytes.
20:19:04 [DanC]
there's stuff like and , which are specified, in a scheme-specific manner, to mean the same thing.
20:19:31 [Ian]
DO: So, canonicalize according to scheme and generic rules, then compare.
20:19:46 [Ian]
RF: The only entity that does the canonicalization is the URI generator; not at comparison time.
20:20:09 [Ian]
RF: Inefficient to canonicalize at compare time.
20:20:15 [TBray]
20:20:33 [Stuart]
ack DaveO
20:21:29 [TBray]
no, paul's in the room with me, and we hear it but aren't doing it
20:21:35 [Ian]
RF: Making a URI absolute is scheme-independent. That's required so we can add schemes later on.
20:22:06 [Ian]
DC: There was a backlash in the XML community about saying absolutize.
20:22:15 [Ian]
TB: That was a different issue.
20:22:40 [TBray]
20:23:01 [Ian]
DC: I don't understand the difference.
20:23:08 [Stuart]
20:23:14 [Ian]
DO: Namespaces used as identifiers rather than for dereferencing.
20:23:43 [Ian]
DO: Requiring absolute URIs was meant to facilitate authoring.
20:24:14 [Stuart]
ack TBray
20:25:47 [Ian]
TB: I hear people arguing that string comparison necessary. I think there needs to be a statement of principle to get good results:
20:25:55 [Ian]
a) don't %-escape unless you have to.
20:26:04 [Ian]
b) use lowercase when doing so.
20:26:09 [Ian]
TB: Where do we take these suggestions?
20:26:40 [Ian]
TB: (a) We have a section on the arch doc on comparing URIs or (b) ask I18N WG to deal with this.
20:26:48 [Ian]
RF: Or add a stronger suggestion to the URI spec itself.
20:27:01 [Ian]
TB: That's a wonderful answer.
20:27:08 [Stuart]
ack Stuart
20:27:20 [Ian]
RF: I can add this to the issues list (section on URI canonicalization). I can't promise that it will be answered there.
20:27:41 [Ian]
DC: I don't think we should punt this entirely.
20:28:09 [Ian]
DC: For URIs, it's fine to do string compare. For URI references, it's fine to absolutize and then do string compare. That works for me.
20:28:28 [Ian]
SW: I agree with TB that we should have something in arch doc. That should be in sync with the emerging URI spec.
20:28:50 [Ian]
DO: How about as little as "there are good rules for doing this; go see the URI spec and the IRI specs for more info..."
20:28:58 [DanC]
"Can the same resource have different URIs? Does http://WWW.EXAMPLE/ identify the same resource as http://www.example/?"
20:29:04 [DanC]
20:30:03 [Ian]
DC: Is it useful to do a finding in the mean time?
20:30:16 [Ian]
IJ: I hope to harvest from Dan's FAQ.
20:30:28 [Ian]
TB: I think that if in arch doc, probably don't need a finding.
20:31:10 [Ian]
Action IJ: Harvest from Dan's FAQ.
20:31:18 [Ian]
Resolved: the Arch Doc should mention this issue.
20:31:48 [Ian]
20:31:54 [Ian]
DO: Possible regrets for next week.
20:31:57 [Zakim]
20:31:59 [Ian]
NW, SW: Regrets.
20:32:00 [Zakim]
20:32:02 [DanC]
order? next meeting was earlier in the agenda.
20:32:05 [Ian]
PC: Tentative regrets.
20:32:06 [DanC]
we're adjourned, yes?
20:32:15 [Ian]
20:32:37 [Zakim]
20:32:41 [Roy]
Roy has left #tagmem
20:32:41 [Zakim]
20:32:44 [Zakim]
20:32:48 [Ian]
RRSAgent, stop