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

[Minutes] 22 July TAG teleconf (arch doc, httpRange-14, uriMediaType-9, URIEquivalence-15)

From: Ian B. Jacobs <ij@w3.org>
Date: Tue, 23 Jul 2002 18:23:07 -0400
Message-ID: <3D3DD74B.4010805@w3.org>
To: www-tag@w3.org


The minutes of the 22 July 2002 TAG teleconf are
available at HTML [1] and as text below.

  - Ian

[1] http://www.w3.org/2002/07/22-tag-summary

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

    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
       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
      * 2.2 Update on other findings
      * 2.3 httpRange-14
      * 2.4 uriMediaType-9
      * 2.5 RFC3023Charset-21
      * 2.6 URIEquivalence-15
      * 2.7 Postponed

   2.1 Architecture Document


           Ian: I was relieved of some AB admin duties.
           (e.g. meeting summaries).

           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.


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

           # Action DC 2002/07/08: Propose text for
           section 1.1 (URI Schemes)

           re my action, I'm about 2/3rds of the way
           thru; see FAQ.

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

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

           From the FAQ: "each valid use of a URI
           reference unambiguously identifies one

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

           It's not clear that we're saying the same

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

    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
           + Action PC 2002/07/08: Propose alternative
             wording for finding regarding IANA
             registration. Refer to "How to Register a
             Media Type with IANA (for the IETF tree) "
             (Not done)
     2. Qnames as identifiers:
           + Action NW 2002/07/15: Republish finding. Can
             we close qnameAsId-18?
             Resolved: This finding is approved.
             Action IJ: Update status
     3. Formatting properties:
           + What is status of issue
             Resolved: This finding is approved.
             Action IJ: Update status

   2.3 httpRange-14

    See issue httpRange-14 and thread started by Tim

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

      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.


      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.
           + Action TBL: Get a reply from the IETF on the
             TAG finding.

      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

   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

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

           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

           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.

        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

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

        "Can the same resource have different URIs?
        Does http://WWW.EXAMPLE/ identify the same
        resource as http://www.example/?"
        -- FAQ on URIs

        DC: Is it useful to do a finding in the mean
        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

    Resolved: the Arch Doc should mention this issue.

   2.7 Postponed

     1. 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 discussions from 24 Jun TAG teleconf.
     2. augmentedInfoset-22:
           + 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.

     Ian Jacobs, for TimBL
     Last modified: $Date: 2002/07/23 22:20:09 $
Received on Tuesday, 23 July 2002 18:26:20 UTC

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