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

[Ian]

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

[Ian]
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".

[TBray]
first principle in arch doc *is* Use URIs: All important resources SHOULD be identified by a URI.
[Ian]
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.
[DanCon]
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
[Ian]
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.
[DanCon]
"The representations of a resource". hmm..
[Ian]
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.
[DanCon]
"All important resources SHOULD be identified by a URI." hmm... SHOULD is for agents... which agent SHOULD do something here?
[Ian]
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."
[DanCon]
http://www.w3.org/2001/tag/doc/ures14.html
[Ian]
TB: Make sure that people understand that the abs reference must exist; you may use relative refs operationally.
[DanCon]
"each valid use of a URI reference unambiguously identifies one resource."
[Ian]
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.)
[DanCon]
"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.
[TBray]
Indeed they're not
[DanCon]
?
[ian_]
TB: We need more carefully written thoughtful opinions before we can discuss this.
[timmit]
(I wonder about Universal Item Identifier III = uriref with a new name)
[Roy]
"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.
[timmit]
Yes - problem is: The "reference" bit is means "strng as actually occurs in referring document' and also "thing with a hash". Overloading.
[ian_]
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.
[DanCon]
from my FAQ: Is http://example/aPath/myDoc.html#section2 a URI?
[ian_]
TB: This is a URI Reference, by definition.
[DanCon]
does http://example/aPath/myDoc.html#section2 refer to a resource?
[ian_]
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.
[timmit]
rdf:Resource = new:Item
[DanCon]
timbl: we could say that http://example/aPath/myDoc.html#section2 refers to, say, an item, rather than a resources.
[ian_]
Proposal: Resources (URI) and Items (URI References).
[timmit]
../foo is not a URI.
[ian_]
TB: Everything that is important should have an absolute URI reference.
[timmit]
Tim: everything should be id'd by an UII.
[ian_]
TB: "Absolute URI Reference"
[Roy]
TB said Everything should be identifiable by a URI reference.
[ian_]
DC: "Absolute URI Reference" is not in RFC2396.
[timmit]
URI reference is like qname - a way to refer to a URI
UII reference is like qname - a way to refer to a UII
[DanCon]
struggling with terminology... that's what this group is here for, no?
[ian_]
TB Summarizing:
a) Absolute URI ref for everything (includes resources and items)
b) OPerationally may have relative URI ref.
[Roy]
absURI#frag == "indirect resource"?
[timmit]
Non-relative URI reference == new: UII.
[ian_]
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.
[Roy]
On uri@w3.org, please.
[ian_]
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.
[DanCon]
Roy, I sent a request for a standardized term for 'absolute URI reference' several years ago.
[ian_]
IJ: What is the significant difference between a resource and an item.
[Roy]
DC, right -- that's already on the issue list.
[DanCon]
hmm... why not GET a mailbox to get its state?
[ian_]
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.
[DanCon]
resource and protocol resource... I could go with that.
[ian_]
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.
[DanCon]
"There's a universe of resources; important ones should be identified by absolute URI references" <- I can buy that.
[Roy]
identified --> identifiable by URI references.
[ian_]
Why identifiable?
[Roy]
because then it is okay to be relative
[ian_]
Ok.
[DanCon]
?
hmm... ok.
[TBray]
2 has lots of representations :)
[ian_]
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.
Proposal:
  1. Define URI to be what we want.
  2. Say we hope to get 2396 changed
[DanCon]
old:AbsoluteURIReference = new:URI
old:URIReference = new:URIReference
[ian_]
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 $