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

Summary of 1 April 2002 TAG teleconference

From: Ian B. Jacobs <ij@w3.org>
Date: Mon, 01 Apr 2002 13:15:15 -0500
Message-ID: <3CA8A3B3.9050702@w3.org>
To: www-tag@w3.org

The meeting summary [1] is available on the Web and
is quoted below as text.

   - Ian

[1] http://www.w3.org/2002/04/01-tag-summary.html

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

                Summary of 2002-04-01 TAG meeting

    Note: This is an edited version of the 1 April 2002
    TAG IRC log

    Previous meeting: 25 March | Next meeting: 8 April

    Participants: Tim Berners-Lee (TBL, Chair), Tim Bray
    (TB), Paul Cotton (PC), Roy Fielding (RF), David
    Orchard (DO), Stuart Williams (SW), Ian Jacobs (IJ,

    Regrets: Chris Lilley, Dan Connolly, Norm Walsh

Agenda items

      * Review of previous minutes, action items
      * Issue: When are two URI variants considered
      * Microsoft security alert regarding HTTP GET
      * What should a "namespace document" look like?
        (Issue namespaceDocument-8)
      * Issue: RFC 3025

Action item summary

    Completed action items:
      * TB: Work on bullet three of introduction to
        architecture. See email from TB.
      * NW: Send revision of "What does a document mean?"
        to www-tag. See email from NW.
      * IJ: Accept issue http-range-14 and refer to email
        from Tim. See email from IJ.

      * IJ: Integrate/combine one-page summaries. IJ has
        started this (awaiting some comments from TAG).
        Note also that this is likely to subsume DO's
        action to write text about "Web as information
        space", to be integrated by IJ.
      * TBL: Take question of HTTP Query to W3C/IETF
        liaison (issue whenToUseGet-7). TBL has sent
        message, awaiting acknowledgment.

      * TBL: Draft three points for TAG presentation to AC
        in May 2002
      * DC, SW: Revise findings on uriMediaType-9,
        incorporating 25 Mar discussion points.
      * TB: Extract issues for TAG from thread on
        boundaries for the Web

    New actions appear in minutes.


      * Accept issue URIEquivalence-15 (When are two URI
        variants considered identical?)
      * Accept issue HTTPSubstrate-16 (RFC 3025)


   Review of previous minutes, action items

           Problem with previous minutes?

           [None expressed]

   Issue: When are two URI variants considered identical?

    See email from Joseph Reagle.

    Resolved: Accept this issue at URIEquivalence-15.

    Action IJ: Add URIEquivalence-15 to the issues list.

    Action TBL: Write up the gist of this discussion as a

   Microsoft security alert regarding HTTP GET

           TBL: Microsoft put up and withdrew a security
           announcement about HTTP GET/POST. The
           suggestion was to turn off GET in servers. W3C
           Team discussed this with various people in
           Microsoft and the security announcement
           disappeared. However, this is not resolved; W3C
           Team may take some action on this. This is
           related to issue whenToUseGet-7. Is there
           consensus that GET should be used for form
           actions that do not have side effects, and POST
           for those that do? I'd like a resolution from
           the TAG asap on this.
           DO: I am unprepared to discuss this today.
           TBL: I thought we had reached consensus based
           on previous discussions.
           Homework: Read Web Architecture from 50k feet.
           TBL: I think this is a problem since there is
           evidently a problem, but the impression that
           HTTP GET is bad is unfortunate.
           PC: I also would like to postpone this issue so
           that I can look into it.
           TB: I think that on the face of it, TBL's
           assertion on GET/POST is correct. If PC and DO
           look into this and find that this is the case,
           please indicate quickly by email. HTTP asserts
           what TBL asserts, I note.
           TBL: I don't expect this to be contentious.

   What should a "namespace document" look like? (Issue

    See issue namespaceDocument-8 in the issues list.

           TBL: Are we going to get caught in two

          1. URIs in general
          2. Namespaces

     Digression into mailing list policy

           TBL: How do we proceed on namespaces

           TB: Last week we took this to www-tag. www-tag
           didn't touch this all week. Do we have more
           light to shed on it? I volunteer to point
           www-tag at this and try to generate some new
           PC: I agree with TB that www-tag didn't take
           this up. Perhaps we should be clearer about
           what we want www-tag to discuss during a given
           TBL: By "take this to www-tag", I mean "TAG
           participants please discuss on the public
           list." We're not looking to delegate this to
           people on www-tag.
           TB: There is precedent for this in the XML
           IJ: Yes, please let's tell www-tag how we
           expect them to participate.
           PC: I agree that if TAG participants discuss,
           that will give www-tag an idea of what we want
           to discuss during the week.

           [There is general sentiment that TAG
           participants are having trouble with the
           quantity of email]

           TBL: It helps if people refer to issues by
           TBL: Perhaps I should contribute something to
           the theses about how namespaces are used with
           TB: You've already done this (and explained
           problems with indirection in some cases).

     Back to issue namespaceDocument-8

           TBL: So perhaps give cases when human readable
           or machine readable more useful, and that both
           share the quality of being able to pursue
           TB: I felt like rug pulled from under me last
           week by saying namespace documents not an
           interesting class.
           I am also bothered by fact that there are two
           contrary types of information to put there.
           When you use one, it gets in the way of the
           TBL: Maybe we can distinguish two cases:

          1. In the HTML namespace case, the namespaces
             are created only rarely, so the namespaces
             are well-known. The information is human
             readable, and generally the semantics are not
          2. In the semantic web case, information in the
             namespace may change often. And there is more
             machine-readable information available.

           TB: That's a plausible world view. TBL should
           write this up. I suggest that positing case A
           as "HTML" case is not a great idea. In general,
           this is the "XML" case.
           PC: What do we do about the common practice of
           having nothing at the end of a namespace?
           TBL: Educate them that it's useful to put
           something there.
           IJ: It seems sufficient to say "Good idea to
           put something there." Don't think "deprecated
           to put nothing there" is useful.
           TB: I'm not sure whether something should
           always be there; information may be problematic
           if the type of information is in active
           conflict for a given use case (e.g., some
           information may be for machines and may confuse
           TBL: The only conflict I can see is that a
           person looks up some information and there's no
           style sheet so that it's not human-readable.
           SW: Are we expecting a single sort of document
           when one dereferences a namespace URI?
           TBL: Because we have two applications, I think
           we've dropped the goal of "one type of document
           TBL: Perhaps we should say that a
           machine-readable document should have style
           sheets to make the information human-readable.
           DO: I think we're still debating whether one
           type of document only.
           TB: I think that if we could achieve consensus
           about what should be at the end of a namespace,
           we'd make great strides towards a
           machine-processable Web.
           TBL: Suppose we have an RDF document with a
           style sheet (could be DAML or RDDL document
           with comments).
           DO: I think that unless we can tell people what
           type of document to put there, we might tell
           people not to put something there.
           TB: All ns doc says is: For this to work, you
           are not required to put a schema at the end of
           the namespace URI.
           TBL: The RDF version of RDDL would be much more
           powerful from the sem web point of view; and
           much more extensible. I need something there
           that an RDF processor would be able to use to
           extract RDF triples.
           TB: What about HTML document with RDF
           assertions embedded?

           Ian, for the minutes, I asked TimBL whether he
           could live with XHTML with RDF inside

           TBL: Architectural piece missing - whether RDF
           assertions are quoted or to be processed, etc.
           One might put FYI information for the browser;
           something not part of document itself.
           TB: It seems to me unlikely that anyone could
           be held responsible for something hidden from
           TBL: In that, RDF is not part of document.
           TB: It is if the person knows about it and is
           prepared to deal with it.
           IJ: Can we get consensus over machine-readable
           use case?
           TB: I can put up a human-readable resource with
           embedded machine-readable information. And I
           assume that an RDF processor can get at that
           information.TBL seems uncomfortable with this
           TBL: This is an architectural problem that we
           can fix. Neither HTML nor RDF specs address
           this. We could say that it is useful to embed
           RDF in HTML documents, so that if you have an
           RDF processor reading an HTML document, it can
           slurp it up. We can put RDF in HTML documents
           and do the RDDL thing. We can put HTML wrappers
           around RDF. At the moment, and RDF parser knows
           no other namespaces.
           DO: When we were talking about this at ftf
           meeting, we talked about the idea of taking an
           XML Schema document and embedding RDF in
           TBL: Yes. We just have to make the statement
           that these RDF assertions are part of the
           DO: If a RDDL document says "Treat embedded RDF
           as RDF assertions," isn't this sufficient?
           TBL: Why not say this in general for (x)html?
           DO: Seems fine to me.
           TB: Yes, seems awfully useful.
           TBL: I propose someone write this up as a TAG
           SW: Could follow up with Brian McBride.
           TBL: So, RDF processors ignore HTML elements,
           and process contents.
           TB: Rather - It treats the HTML tags like
           (TBL: The HTML still needs to be well-formed).
           TBL: And then, once it encounters RDF, it needs
           to process RDF until the end of RDF.
           Action IJ and TB: Find someone in Team or RDF
           world to write this up; keep SW in the loop.
           DO: So, what about the indirection question?
           TB: RDF gives you the indirection.

           I wonder if this is related to what TimBL was
           discussing this morning about MS and
           deprecating GET:

           PC: Why doesn't RDF namespace work like any
           other namespace?

           TB: I kind of agree with PC - I'm not sure
           what's driving TBL's architectural concern,
           but that's not a problem if TBL is going to
           make it go away

           TBL: So a way forward: HTML doc with RDF
           embedded is something we should more or less
           standardize since it can contain
           human-readable/machine-readable information and
           have indirections.

           TB: Some will take this as the death knell for
           xlink. I think we want to recommend putting a
           directory of resources.
           TBL: We said both human/machine-readable
           resources is good. And it's good to standardize
           these things. With the TAG finding of saying
           RDF-in-HTML-interpreted-as-RDF, then we get the
           best of both worlds.
           DO: The issue is whether RDF is required to be
           THE machine-readable content. Do you want to
           preclude RDDL?
           TB: Given that anything you can do in XLink you
           can also do in RDF, I can't see why you would
           want to pick one and just say "use that".
           DO: Allow people to express in XLink and derive
           RDF from that, as well.
           IJ: I heard:

           + One should use RDF+HTML
           + One may use something else.

           TB: We could say:

           + Depending on the situation, both human and
             readable information are useful in a
             namespace document.
           + A good way to do this (without precluding
             either human or machine readable information)
             is to use RDF+HTML.

           TB: If W3C wants to standardize how, that would
           be go.
           SW: I am willing to write this up.
           TB: Take RDDL spec and s/xlink syntax/rdf
           TBL: I heard DO ask for clarification about
           must v. should. We are moving towards SHOULD.
           IJ SUMMARIZING:

           + Authors should put something at the end of a
             namespace URI
           + Since both human and machine-readable
             information is useful, should use HTML+RDF.

           DO: There "may" be machine-readable things.
           IJ: I hear DO suggesting that the requirement
           for human-readable information is stronger than
           that for machine-readable.
           TB: Yes, I would support that.
           DO: Saying HTML at the top seems ok, but that's
           not quite sufficient for human-readable...
           TB: So set expectations that what one will find
           there is human-readable.
           Action SW: Write down these suggestions for
           namespace documents.

   Issue: RFC3025

           Proposal: Accept and discuss HTTPSubstrate-16
           based on email from Mark Nottingham about RFC

           RF: IESG says that HTTP should not be used as
           substrate. Mark Nottingham asks how this
           differs from W3C's position.

           TBL: I think the IESG was saying, if you're
           using what looks like HTTP, then firewalls will
           think people are browsing. So you should call
           it something different and use a different port

           TBL: I think W3C would be "HTTP is there;
           people benefit from reusing it (proxies, caches
           work), so reusing HTTP is good. It's expensive
           to reinvent HTTP. Just creating a new protocol
           on a different port is disruptive." To draw an
           arbitrary line that fragments the architecture
           is bad; makes it more difficult to set up and
           use proxies, less efficient, etc.
           TB: Most people creating Web service machinery
           are building over HTTP. The world is doing this
           and the IETF is saying you shouldn't?
           RF: The IETF has been saying you shouldn't for
           about 6 years.If you look at RFC 3205, the
           recommendation is that, if you're using HTTP,
           you should be using it for the Web. But don't
           take Keith's definition of the Web as
           rigid.Henrik Nielsen wrote up comments about
           this RFC and sent in during comment period.
           TBL: XML Protocols WG wrote up criticism.
           Apparently XML Protocols WG's comments bounced.
           RF: When Keith received large commentary, you
           wouldn't see large reply to it (no Working
           Group for this document).
           TBL: Yes, I think there were some perceptions
           of procedural problems, and issues of
           TB: This raises another point - security and
           Web services. Somebody needs to make the point
           that security policies on port numbers is
           probably the wrong way to go. Despite what the
           IETF thinks, people are deploying a variety
           applications over HTTP. The people who build
           firewalls need to look at that.
           DO: I think that the XML model breaks the
           classical model; people create new applications
           and the port number mechanism doesn't scale.
           TBL: Good point. There's another point - the
           IETF control over applications by giving them
           port names doesn't scale.You also gain a lot by
           sharing applications in a common information
           RF: If you put the question to me whether SOAP
           can exist over HTTP and remain consistent with
           the Web model, I would say "no", since
           semantics are different in a SOAP message.
           Keith wasn't dealing as much with with
           protocols we are building today, but protocols
           designed to get through firewalls (tunneling
           through port 80).

           Tunneling using non-strandard tweaks

           RF: If you do a get on a printer, either
           nothing would happen or a printer would break.
           TB: From a security point of view, given that
           people are going to be running applications by
           XML over HTTP, we've given security people
           hooks they can use, in the form of namespaces.
           You can filter based on namespace, for example.
           The points being thrashed out on www-tag last
           week - whereas it's possible to do RPC over
           HTTP cleanly, apparently SOAP doesn't do it
           cleanly. Should we be worried about this?
           DO: I think some companies are thinking about
           this type of security mechanisms.
           RF: There are people doing this; looking inside
           content since 1995.
           Resolved: Accept issue HTTPSubstrate-16.
           Action IJ: Add HTTPSubstrate-16 this to issues
           TBL: Should you use a different port than 80?
           Should you design another protocol? (No).
           RF: My concern is that the scope of this issue
           is huge.
           TBL: As Larry Masinter pointed out, there's no
           HTTP WG right now.
           RF: I think it would make sense for us to put
           together a substantial criticism of RFC3205 and
           work on it as a group. Maybe using DC's wiki
           Action RF: Kick this off (by sending to
           IJ: Can we post agenda to www-tag and tell them
           to help us on specific issues?
           TB: Yes. Tell them to focus and put issue
           number in their emails.
           TBL: Yes, let's do that.
           Action IJ: Put mailing list policies on agenda
           for next week. Question of how www-tag can best
           participate and TAG can focus.
           SW: What about a TAG IG list? (and leaving
           www-tag for TAG participants write only, for
           doing work in public).
           IJ: Would having two lists help TAG
           participants write more? Or would this just
           mean following two lists?
           TB: I am willing to ask www-tag folks for input
           on how to proceed.
Received on Monday, 1 April 2002 13:15:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:31 UTC