W3C | TAG | Previous:29 Jul | Next: 19 Aug

Minutes of 12 August 2002 TAG teleconference

Nearby: Teleconference details issues list www-tag archive

1. Administrative

  1. Roll call: TBL, SW, DC, PC, RF, TB, IJ. Regrets: DO, CL, NW
  2. Accepted 29 July minutes
  3. Accepted this agenda
  4. Next meeting: 19 Aug. Regrets: PC, DO, TBL (2 weeks). SW to chair on 19 August.

2. Technical

  1. Architecture document
  2. Postponed

2.1 Architecture Document


DC: I have not asked the IESG yet. Not awaiting reply. I was going to ask the IESG. There's an ICANN PSO that W3C is party to (through Martin and Danny). I asked whether that would be a conduit. I got a response from Martin. But the ICANN PSO may not be useful here. I am starting to conclude that the straightforward way to ask the IETF a question is through an internet draft.

TB: Wouldn't have to be long. Could just reaffirm that (1) important things should be part of the web (2) should have dereferenceable URIs (3) I* should host these things.
DC: Could publish finding Mapping between URIs and Internet Media Types as an Internet Draft. It reads:
"The TAG requests that IANA, the authority which adminsters the registry of Internet media types, be committed to providing persistent and dereferencable URIs that return a document containing human ..." I would rather someone volunteer to do an internet draft instead of me asking the IESG. Issue is what to do with incoming mail.
RF: What about "crisp" mailing list: Cross Registry Information Service Protocol (crisp)?
TBL: So the action could be phrased in response to that.
TB: I think we should not let this issue fade away. We should do whatever it takes so that the IETF knows we think this belongs in Web space.
TBL: Slight revision: (1) Put on the Web (2) Use HTTP to do so.
[DC makes a comment about how much time he thinks this will take: about 4 months.]
DC: The people here think that LDAP is the way to solve the problem. In general, the IETF is pretty happy with the idea that every new thing needs a new protocol. "If you're not serving up hypertext docs, you need a new port number, a new way to marshall arguments, etc." I agree with TB that this is worth doing, but it's a big hill. I think the IETF doesn't believe that anything that does GET should use HTTP.
TBL: So how do we proceed?
DC: Maybe I can ask for volunteers on www-tag.
TBL, TB: Good idea.
TBL: Is the CRISP list the appropriate forum?
RF: Don't know. I haven't read; don't know how open they are to new ideas. You can send to the applications area.
DC: This was a proposed WG when RF first notified us. Now it's a WG....
Action DC: Ask www-tag for volunteers to work with TAG (and possibly IETF) on HTTP URI stuff; CRISP
Action IJ: Indicate that issue URIMediaType-9 is not indicated as closed.

On the 9 August draft of the Architecture Document

IJ: I made available (quietly) a new draft, but this is not related to the action item (due at the end of the month). Making progress, but I have a fair amount to do.

TB: First principle in arch document should be "important things should have URIs".

first principle in arch doc *is* Use URIs: All important resources SHOULD be identified by a URI.
DC: The table could come in handy here: If you have a protocol that p(short-string) -> document, you should use existing stuff. Create a table of patterns that we use to solve problems.
is the square-boxy thingy supposed to be a definition or something? "Valid use of URI" is described, but not defined, by that box in chapter 1
IJ: Things in boxes are principles. I still have stuff to do in this document.
TB: I think we can usefully ask for input from people before publishing first public WD.
IJ: I need to do things like link from open issues to issues list, etc.
"The representations of a resource". hmm..
TB: Also,
IJ: If you can think of top 3 things where *most people* have been confused.
DC: Don't forget to include where there has been consensus!
TB: Not sure that httpRange-14 has a big impact on the document.
TBL: It did in a past version. Involved s/resource/document.
TB: I think that those comments would be out of sync with current draft.
"All important resources SHOULD be identified by a URI." hmm... SHOULD is for agents... which agent SHOULD do something here?
IJ: Please note that document starts with generalities, and URI references are touched on up front, and then expanded on later.
DC: One approach is to say "URIs include things with # marks". But it's hard to refer to RFC2396 and do that.
RF: The basic problem with treating frag as being equivalent with URIs is that you can't do certain things (e.g., have a third-party monitor).
DC: I rebutted that argument before. Doesn't have to do with whether there's a "#".
RF: Has to do with whether it's a resource.
DC: I don't believe so. First box should read "...identified by an absolute URI reference"
TBL: Remove "absolute"; relative is a shortcut. "All important resources should have an absolute URI reference."
TB: Make sure that people understand that the abs reference must exist; you may use relative refs operationally.
"each valid use of a URI reference unambiguously identifies one resource."
DC: I would need to see something up front (in organizatoin of current document) that says "I'm lying to you." (Since URI refs not mentioned yet.)
"A resource is part of the Web when it is identified by a URI." <- hmm... this suggests resources that haven't been named with URIs aren't part of the web.
Indeed they're not
TB: We need more carefully written thoughtful opinions before we can discuss this.
(I wonder about Universal Item Identifier III = uriref with a new name)
"URI Reference" is a protocol element containing a reference to a resource.
If we want a new name for URI with fragment, I welcome suggestions.
It was originally called a document address.
Yes - problem is: The "reference" bit is means "strng as actually occurs in referring document' and also "thing with a hash". Overloading.
IJ: I suspect it's possible to fix URI -> URI Ref up front and still start with generalities, and attack specifics of URI refs later in the doc.
from my FAQ: Is http://example/aPath/myDoc.html#section2 a URI?
TB: This is a URI Reference, by definition.
does http://example/aPath/myDoc.html#section2 refer to a resource?
IJ: I thought the model was: URIs refer to resources, URI Refs do if the format allows.
RF: The HTTP spec in particular needs specific requirements on the URI syntax that the frag id does not fall within. It doesn't matter to me if we say either:
a) URI -> Rsource, frag is indirect.
b) URIs, URI refs- > Resources.
TBL: RDF has used the word "resource" for an item. Might be easier to change in RDF world.
rdf:Resource = new:Item
timbl: we could say that http://example/aPath/myDoc.html#section2 refers to, say, an item, rather than a resources.
Proposal: Resources (URI) and Items (URI References).
../foo is not a URI.
TB: Everything that is important should have an absolute URI reference.
Tim: everything should be id'd by an UII.
TB: "Absolute URI Reference"
TB said Everything should be identifiable by a URI reference.
DC: "Absolute URI Reference" is not in RFC2396.
URI reference is like qname - a way to refer to a URI
UII reference is like qname - a way to refer to a UII
struggling with terminology... that's what this group is here for, no?
TB Summarizing:
a) Absolute URI ref for everything (includes resources and items)
b) OPerationally may have relative URI ref.
absURI#frag == "indirect resource"?
Non-relative URI reference == new: UII.
DC: I think we need a term for X = absURI [# fragid]
IJ: I can call for suggestions on that term.
TB: In RFC2396, terms, call it a non-relative URI reference.
On uri@w3.org, please.
RF: I'm perfectly open to the notion of saying the URI includes "#frag". I keep getting shot down when I've tried in the past (since W3C not involved in the discussion). I don't want another IRI. I don't want more than one definition of a protocol element. I don't want developers to have to read 14 specs. I am open to new terms; need to do this this week.
Roy, I sent a request for a standardized term for 'absolute URI reference' several years ago.
IJ: What is the significant difference between a resource and an item.
DC, right -- that's already on the issue list.
hmm... why not GET a mailbox to get its state?
TB: I am for a new term. Can we argue a little about the term? What about "resource" and "resource component". You need a resource to get a component.
DC: the thing you called component is the more general term.
resource and protocol resource... I could go with that.
DC: I would rather use "resource" for with frag id, and create another term for the special case (no frag id)
RF: A resource is something that you can return to multiple times. The proposed meaning is inconsistent with my model.
DC: Is the number "2" a resource?
RF: Yes. If you have an identifier for it as a resource, you need to be able to return to it.
TB: What does the "#" have to do with it?
RF: These things are "resourceful", but I'm not sure we can define a consistent set of specs if 1/2 the world says with frag refers to a resource and without does not.
TB: I would take the view that a rseource is anything that has identify (2396) and there is a special class identified by things identified by URIs with no fragments.
DC: "Protocol resource" works for me.
TB: We are saying that both URIs and URI references identify resources.
IJ: I hear URIs pointing to a thing of class=resource, subclass="protocol resource." What not "network resource"?
TBL: UUIDs and similar are not networked necessarily.
IJ: Why would I use one class or the other?
DC: I don't know; I"d have to look at the spec.
"There's a universe of resources; important ones should be identified by absolute URI references" <- I can buy that.
identified --> identifiable by URI references.
Why identifiable?
because then it is okay to be relative
hmm... ok.
2 has lots of representations :)
TBL: Outside of HTTP, no ambiguity between URI ref/URI anyway.
RF: It's easier for me if I don't have to call the things I identify with URI refs "resources." So: "All important resources should have identifiers."
TBL: What we want is to define URI to be (1) frag id optional and is (2) not relative. And URI ref would be URI | relative thingy.
  1. Define URI to be what we want.
  2. Say we hope to get 2396 changed
old:AbsoluteURIReference = new:URI
old:URIReference = new:URIReference
DC: Specs that were careful put "URI reference" in their specs. We're not changing that term.
RF: I think the HTTP spec was careful to say Absolute URI.
Action IJ: Revise document to account for this proposal; send out announcement to www-tag in 24 hours. Make it clear that we may not respond to all feedback. Say that we are not committing to respond, but not to worry; open action items won't just be dropped.

2.2 Postponed

  1. httpRange-14: Need to make progress here to advance in Arch Document.
  2. Internet Media Type registration, consistency of use.
  3. RFC3023Charset-21:
    1. Chris sent information to www-tag. What is necessary to close this issue?
  4. 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. See more comments from Martin.
    1. What should a finding look like for this?
  5. Status of discussions with WSA WG about SOAP/WSDL/GET/Query strings?
  6. xlinkScope-23
    1. Priority of this?
  7. augmentedInfoset-22:
  8. deepLinking-25
    1. Action PC 2002/07/22: Ask Henrik Frystyk Nielsen to provide us with a precis of the ruling. Done: awaiting reply from Henrik.
  9. uriMediaType-9: Status of negotiation with IETF? See message from DanC.

2.3 New issues?

Ian Jacobs, for TimBL
Last modified: $Date: 2002/08/15 13:47:06 $