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

Hello,

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
    archive

       [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 
chair
        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
        done.
      * Action DC 2002/07/08: Ask IESG when IETF decided not to use HTTP
        URis to name protocols.

    [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 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 
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: [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 
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.

      [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

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

    [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 is 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]
           [15]http://www.w3.org/2001/tag/doc/ures14.html

      [15] 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 originall called a document address.

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

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

    [ian_]
           TB: This is a URI Reference, by definition.

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

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

    [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 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.

    [timmit]
           rdf:Resource = new:Item

    [DanCon]
           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

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

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

    [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. [20]httpRange-14: Need to make progress here to advance in Arch
        Document.
     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
        strings?
           + 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
             Henrik.
     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