W3C home > Mailing lists > Public > www-tag@w3.org > August 2002

[Minutes] 12 August 2002 TAG teleconf (architecture document)

From: Ian B. Jacobs <ij@w3.org>
Date: Mon, 12 Aug 2002 17:28:56 -0400
Message-ID: <3D582898.6000901@w3.org>
To: www-tag@w3.org


Minutes from the 12 August TAG teleconference are
available as HTML and as text below.

  - Ian

[1] http://www.w3.org/2002/08/12-tag-summary
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

    [1]W3C [2]| TAG | Previous:[3]29 Jul | Next: 19 Aug

       [1] http://www.w3.org/
       [2] http://www.w3.org/2001/tag/
       [3] http://www.w3.org/2002/07/29-tag-summary

                  Minutes of 12 August 2002 TAG teleconference

    Nearby: [4]Teleconference details  [5]issues list  [6]www-tag

       [4] http://www.w3.org/2001/tag/group/#remote
       [5] http://www.w3.org/2001/tag/ilist
       [6] http://lists.w3.org/Archives/Public/www-tag/

1. Administrative

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

       [7] http://www.w3.org/2002/07/29-tag-summary
       [8] http://www.w3.org/2002/08/12-tag

2. Technical

     1. [9]Architecture document
     2. [10]Postponed

   2.1 Architecture Document

      * Action TBL: 2002/07/15: Create a table of URI properties. Not
      * Action DC 2002/07/08: Ask IESG when IETF decided not to use HTTP
        URis to name protocols.

           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 include 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 [11]Mapping between URIs and 
           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: [12]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 
           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 
           as closed.

      [11] http://www.w3.org/2001/tag/2002/01-uriMediaType-9
      [12] http://www.ietf.org/html.charters/crisp-charter.html

     On the [13]9 August draft of the Architecture Document

      [13] http://www.w3.org/2001/tag/2002/0805-archdoc

      * Action IJ 2002/07/08: Produce WD of Arch Doc. Harvest from
        [14]DanC's URI FAQ. Deadline 30 August

      [14] http://www.w3.org/2001/tag/doc/ures14.html

           IJ: I made available (quietly) a new draft, but this is not
           related to the action item (due at the end fo 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 
           that p(short-string) -> document, you should use existing
           stuff. Create a table of patterns that we use to solve

           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
           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." 
           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 
           DC: One approach is to say "URIs include things with # 
           But it's hard to refer to RFC2396 and do that.
           RF: The basic problem with treating frag is as being 
           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 
           resources should have an absolute URI reference."


      [15] http://www.w3.org/2001/tag/doc/ures14.html

           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

           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 
           <- hmm... this suggests resources that haven't been named 
           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
           It was originall called a document address.

           Yes - problem is: The "reference" bit is means "strng as
           actually occirs 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 
[16]http://example/aPath/myDoc.html#section2 a

      [16] http://example/aPath/myDoc.html#section2

           TB: This is a URI Reference, by definition.

           does [17]http://example/aPath/myDoc.html#section2 refer to a

      [17] http://example/aPath/myDoc.html#section2

           IJ: I thought the model was: URIs refer to resources, URI 
           do if the format allows.
           RF: The HTTP spec in particular needs specific 
requirements on
           the URI syntax that the frag id doesn't 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
           [18]http://example/aPath/myDoc.html#section2 refers to, 
say, an
           item, rather than a resources.

      [18] http://example/aPath/myDoc.html#section2

           Proposal: Resources (URI) and Items (URI References).

           ../foo is not a URI.

           TB: Everything that is important should have an absolute URI

           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 [19]RFC2396.

      [19] http://www.ietf.org/rfc/rfc2396.txt

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

          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 
           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 
           to respond, but not to worry; open action items won't just be

   2.2 Postponed

     1. [20]httpRange-14: Need to make progress here to advance in Arch
     2. [21]Internet Media Type registration, consistency of use.
           + Action PC [22]2002/07/08: Propose alternative cautionary
             wording for finding regarding IANA registration. Refer to
             "[23]How to Register a Media Type with IANA (for the IETF
             tree) ". Pending.
     3. RFC3023Charset-21:
          1. Chris sent [24]information to www-tag. What is necessary to
             close this issue?
     4. Status of [25]URIEquivalence-15. Relation to Character Model of
        the Web (chapter 4)? See text from TimBL on [26]URI
        canonicalization and [27]email from Martin in particular. 
See more
        [28]comments from Martin.
          1. What should a finding look like for this?
     5. Status of discussions with WSA WG about SOAP/WSDL/GET/Query
           + ACTION DO 2002/06/24: Contact WSDL WG about this issue
             (bindings, query strings and schemas) to ensure that 
it's on
             their radar. See [29]discussions from 24 Jun TAG teleconf.
     6. [30]xlinkScope-23
          1. Priority of this?
     7. [31]augmentedInfoset-22:
           + [32]Request from Tim Bray to decide this issue 
(disposition =
             closed). Pushback from Simon St. Laurent.
           + ACTION DC 2002/06/17: Talk to XML Schema WG about PSVI.
             Report to tag, who expects to decide whether to add as an
             issue next week. DanC has sent email; awaiting reply 
from XML
             Scheme WG.
     8. [33]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
     9. [34]uriMediaType-9: Status of negotiation with IETF? See
        [35]message from DanC.
           + Action TBL: Get a reply from the IETF on the TAG finding.

      [20] http://www.w3.org/2001/tag/ilist#httpRange-14
      [21] http://www.w3.org/2001/tag/2002/0129-mime
      [22] http://www.w3.org/2002/07/08-tag-summary#media-types
      [23] http://www.w3.org/2002/06/registering-mediatype
      [24] http://lists.w3.org/Archives/Public/www-tag/2002Jul/0323.html
      [25] http://www.w3.org/2001/tag/ilist#URIEquivalence-15
      [26] http://www.w3.org/DesignIssues/Axioms.html#canonicalization
      [27] http://lists.w3.org/Archives/Public/www-tag/2002May/0161
      [28] http://lists.w3.org/Archives/Public/www-tag/2002Jul/0275.html
      [29] http://www.w3.org/2002/06/24-tag-summary.html#wsa-get
      [30] http://www.w3.org/2001/tag/ilist#xlinkScope-23
      [31] http://www.w3.org/2001/tag/ilist#augmentedInfoset-22
      [32] http://lists.w3.org/Archives/Public/www-tag/2002Jul/0159.html
      [33] http://www.w3.org/2001/tag/ilist.html#deepLinking-25
      [34] http://www.w3.org/2001/tag/ilist#uriMediaType-9
      [35] http://lists.w3.org/Archives/Member/tag/2002Jun/0095.html

   2.3 New issues?


     Ian Jacobs, for TimBL
     Last modified: $Date: 2002/08/12 21:27:16 $
Received on Monday, 12 August 2002 17:32:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:53 UTC