W3C | TAG | Previous:15 Jul | Next: 29 July | IRC log

Minutes of 22 July 2002 TAG teleconference

Nearby: Teleconference details · issues list · www-tag archive

1. Administrative

  1. Roll call: SW, DC, IJ, PC, NW, TB, RF. Regrets: CL, TBL, DO (on IRC)
  2. Accepted 15 July minutes
  3. Next meeting: 29 July. Regrets: NW, SW. Possible regrets: DO, PC
  4. Confirmed status of completed actions
  5. September meeting arrangements

    Action TB: Send information about hotels to TAG.

1.2 Completed actions?

  1. Action TB: 2002/07/15: Clarify sentence on what an HTTP URI refers to. (Done)

1.3 New issues?

  1. Accepted as issue contentTypeOverride-24: Overriding HTTP content-type with a URI reference.See email from TBL.
  2. Accepted as issue deepLinking-25: "Deep linking illegal" bad practice? See email from Tim Bray and Links and Law

On deepLinking-25:

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.
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.
RF: I agree with you in principle. But the ruling in this case was about one news org taking content from another.
Action PC: Ask Henrik Frystyk Nielsen to provide us with a precis of the ruling.
PC: We should tell people that if they publish a URI and don't want someone to get at it, what they can do.
TB: There has been litigation about this several times. I think this will keep coming up.
RF: I agree with the principle in general. I am worried about the actual facts of the case.
DC: 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.

2. Technical

2.1 Architecture Document

[DanC]

Ian: I was relieved of some AB admin duties. (e.g. meeting summaries).
[Ian]
IJ: Steve Ziles picking up some of my duties. When I get new draft of Process Doc to AB, I will be able to focus more on arch doc.
[DaveO]
woohoo!
[Ian]
CLOSED TBL 2002/05/05: Negotiate more of IJ time for arch doc
ClOSED RF 2002/06/24: Write a paragraph on technical and political aspects of URIs and URI References. (Done).
[Ian]
# Action DC 2002/07/08: Propose text for section 1.1 (URI Schemes)
[DanC]
re my action, I'm about 2/3rds of the way thru; see FAQ.
[Ian]
# Action DC: 2002/07/15: Generate tables of URI scheme props from RDF. (Progress)
DC: I started working on the URI scheme table. Idea was to take column headings. I couldn't find any column headings that generalized to whole URI schemes. Some progress.
TB: I have revised my comments. See edits from SW as well. I think SW's and Chris Ferris's points are good ones.
[Ian]
# Action DC 2002/07/08: Ask Michael Mealing when IETF decided not to use HTTP URIs to name protocols. Awaiting reply.
DC: I need to get more from MM. Harder to find out "what's going on there". I am not willing to do intelligence on the whole IETF.
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).
DC: No way to get a clear answer unless policy part of an RFC.
RF: We can ask the IESG a question about what drafts they are rejecting.
DC: Do they *owe* me an answer?
RF: I Don't know.
DC: I can try. But last time I put something on their agenda, it took them 9 months to answer.
Resolved: Change action from ask Michael Mealing to ask the IESG. Change to "if and when" IETF decided...
DC: As for action about the table of URI schemes, I find not useful. I hope the table is not in the arch doc. I find it to be extremely misleading.
The "Relative URI" column is misleading. It's supported syntactically for all schemes.
RF: URN scheme doesn't allow "/" for hierarchy.
DC: But if there's a slash in there, then there's hierarchy.
SW: Is there hierarchy to mailto?
RF: Find the useful bit and put into the table.
DC: I tried and was unable.
DC: Maybe a way to rephrase the relative URI column to be useful. For spelling equivalence, if you want to be sure - spell the same way. I couldn't make sense of functional equivalence at all. For admin, I couldn't find pattern.
RF: I liked that because it pointed out that there was no diff between DNS authority and URN authority.
DC: That's a point worth making, but the table doesn't make it. (The differences between URNs and DNS are not interesting, but the table doesn't convey that.)
RF: Can we play with the RDF?
DC: Yes.
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.
TB: Something modest and hand-prepared would probably do the job.
[DanC]
From the FAQ: "each valid use of a URI reference unambiguously identifies one resource"
[Ian]
IJ: Sounds something like what Norm wrote: "A URI identifies a resource that is amenable to unambiguous interpretation by recursive application of a finite set of specifications, beginning with the specification that governs the scheme of the URI."
[DanC]
It's not clear that we're saying the same thing.
[Ian]
IJ: I think we should try to align there.
#CLOSED Action SW 2002/07/15: Draft text for arch principle on absolute addressing preferred over context-sensitive addressing. (Done)
TB: I think SW's draft is solid. Some feedback on www-tag.
SW: I will include the bang-style addressing (email) in the rationale.
DC: "Does the Web use local or global naming?"
TB: I'm not sure that the anecdote adds much to the discussion.
DC: Global naming scales better in certain ways (generic principle). I think the principle applies to absolute URI refs (but not "../foo").
RF: NEWS URIs are context dependent.: 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.: E.g., reference to a newsgroup that is relative to your local access point.: Whereas nntp: is a global context.: The details get nasty.: You need to identify what you mean by resource first, then say whether the resource needs to be globally consistent ("sameness" must be global). When we insert this text in the arch doc, we need to be concerned about the nasty details.: I suggest not to say "resource or concept", just "resource".

Remaining open action items:

  1. Action CL 2002/07/08: Propose text for section 2 (Formats). Deadline 30 July.
  2. Action IJ 2002/07/08: Produce WD of Arch Doc. Deadline 30 August.

2.2 Update on other findings

See also: findings.

  1. Internet media type registration, consistency of use.
  2. Qnames as identifiers:
  3. Formatting properties:

2.3 httpRange-14

See issue httpRange-14 and thread started by Tim Bray.

DC: There is a stalemate between positions of TBL and RF. Two rational arguments.
RF: If TBL confirms NW's writings, then I have a simple answer. 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. 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.
TB: I thought there was material talk on the list about the workings of RDF. RDF should be able to talk about resources and representations of resources. If it can't, it's broken.
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.
RF: If the definition is not consistent across all methods, then the definition is wrong.
SW: When TBL talks of "docs" he's talking about document resources (not representations). And RF is referring to representations.
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. The distinction TBL wants to make falls over in practice.
DC: I'd like a term that means "bits + mime type" (other than representation)....
RF: We chose "entity body" since we couldn't come up with a better term...
DC: I refer to bits + mime type as a document. And resources that act like documents, I call "works"
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.
SW: How to make progress on this?
DC: I'm willing to try to convince TBL.
TB: we need language for this (about what an HTTP resource is...) I suggest procedurally that we ask TimBL to react to proposed text and www-tag comments and help us make progress on this issue.
[tim-mtg]
It is possible to have a system in which the publisher of a URI determines what it actually identifies (car or Web page) but all the systems like
Dublin Core which assume blithley that a Web page is identified by its URI have to be put on hold. Until they can check with the publishers of the URI to find out whether in fact the URI identifies something which is not a web page.
[Ian]
Action SW: Persuade TimBL to write an exposition of his position.

2.4 uriMediaType-9

  1. uriMediaType-9: Status of negotiation with IETF? See message from DanC.
DC: TimBL proposed this for June IETF/W3C meeting. Didn't get far then.
DC: We are next meeting 12 November.
SW: I'm not sure what our best course of action is here. Either a mid-November backstop or a possible forum (W3C CG) before then.
SW: Do we need to be more active than that?
DC: I'm at a loss.
SW: Then I propose that we try to get on agenda of CG first, or next IETF/W3C meeting otherwise.

2.5 RFC3023Charset-21

  1. Action CL: Send copy of information sent to tag regarding RFC3023Charset-21 to www-tag. (Open)

2.6 URIEquivalence-15

  1. 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.
TB: This is serious. Martin seems to be saying "deal with it"
DC: Two reasons:
  1. 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.
  2. In general, it's an art to gather that something spelled differently means the same thing.
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?
DC: Shortest path to target is the I18N WG. RFC 2396 applies equally to all URI schemes. Generating absolute from relative URI is not scheme-specific.
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.
RF: Different issues here. 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.
[DanC]
There's stuff like http://www.w3.org:80/ and http://www.w3.org/ , which are specified, in a scheme-specific manner, to mean the same thing.
[Ian]
DO: So, canonicalize according to scheme and generic rules, then compare.
RF: The only entity that does the canonicalization is the URI generator; not at comparison time. Inefficient to canonicalize at compare time.
[Ian]
RF: Making a URI absolute is scheme-independent. That's required so we can add schemes later on.
DC: There was a backlash in the XML community about saying absolutize.
TB: That was a different issue.
DC: I don't understand the difference.
DO: Namespaces used as identifiers rather than for dereferencing. Requiring absolute URIs was meant to facilitate authoring.
TB: I hear people arguing that string comparison necessary. I think there needs to be a statement of principle to get good results:
  1. Don't use %-escape unless you have to.
  2. Yse lowercase when doing so.
TB: Where do we take these suggestions?: (a) We have a section on the arch doc on comparing URIs or (b) ask I18N WG to deal with this.
RF: Or add a stronger suggestion to the URI spec itself.
TB: That's a wonderful answer!
RF: I can add this to the issues list (section on URI canonicalization). I can't promise that it will be answered there.
DC: I don't think we should punt this entirely. 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.
SW: I agree with TB that we should have something in arch doc. That should be in sync with the emerging URI spec.
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..."
[DanC]
"Can the same resource have different URIs? Does http://WWW.EXAMPLE/ identify the same resource as http://www.example/?"
-- FAQ on URIs
[Ian]
DC: Is it useful to do a finding in the mean time?
IJ: I hope to harvest from Dan's FAQ.
TB: I think that if in arch doc, probably don't need a finding.
Action IJ: Harvest from Dan's FAQ for arch document.

Resolved: the Arch Doc should mention this issue.

2.7 Postponed

  1. Status of discussions with WSA WG about SOAP/WSDL/GET/Query strings?
  2. augmentedInfoset-22:
Ian Jacobs, for TimBL
Last modified: $Date: 2002/07/23 22:20:09 $