Summary of 2002-04-01 TAG meeting

Note: This is an edited version of the 1 April 2002 TAG IRC log. Last modified: $Date: 2002/04/01 18:17:26 $

Previous meeting: 25 March | Next meeting: 8 April 2002 | TAG home

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

Regrets: Chris Lilley, Dan Connolly, Norm Walsh

Agenda items

Action item summary

Completed action items:

Pending:

Open:

New actions appear in minutes.

Decisions

Minutes

Review of previous minutes, action items

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

Microsoft security alert regarding HTTP GET

[Ian]
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 namespaceDocument-8)

See issue namespaceDocument-8 in the issues list.

[Ian]

TBL: Are we going to get caught in two ratholes?

  1. URIs in general
  2. Namespaces

Digression into mailing list policy

[Ian]

TBL: How do we proceed on namespaces (namespaceDocument-8)?

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 ideas.
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 week.
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 world.
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 number.
TBL: Perhaps I should contribute something to the theses about how namespaces are used with RDF.
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 pointers.
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 other.
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 machine-readable.
  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 users).
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 only".
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?
[Dave]
Ian, for the minutes, I asked TimBL whether he could live with XHTML with RDF inside
[Ian]
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 them.
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 approach.
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 annotations.
TBL: Yes. We just have to make the statement that these RDF assertions are part of the document
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 finding.
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 whitespace.
(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.
[TimBray]
I wonder if this is related to what TimBL was discussing this morning about MS and deprecating GET: http://news.com.com/2100-1001-871771.html
[Ian]
PC: Why doesn't RDF namespace work like any other namespace?
[Ian]
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
[Ian]
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.
[Ian]
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:
TB: We could say:
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 syntax/
TBL: I heard DO ask for clarification about must v. should. We are moving towards SHOULD.
IJ SUMMARIZING:
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: RFC3205

[Ian]
Proposal: Accept and discuss HTTPSubstrate-16 based on email from Mark Nottingham about RFC 3205.

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

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 accountability.
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 space.
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).
[TimBL]
Tunneling using non-strandard tweaks
[Ian]
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 list.
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 web.
Action RF: Kick this off (by sending to www-tag).
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.