W3C | TAG | Previous: 16 Jun teleconference | Next: 30 June 2003 teleconf

Minutes of 23 June 2003 TAG teleconference

Nearby: IRC log |Teleconference details · issues list · www-tag archive

1. Administrative

  1. Roll call: SW (Chair), DC, NW, DO, TB, PC, IJ (Scribe).. Regrets: TBL, RF, CL
  2. Accepted minutes of 16 Jun teleconference
  3. Accepted this agenda
  4. Next meeting: 30 June. Regrets: PC, DO.
  5. Summer meeting planning; see request from Stuart. We are likely to cancel 18 and 25 July.

    Action SW: Send proposed August schedule to TAG.

2. Technical

  1. abstractComponentRefs-37
  2. Architecture Document
  3. contentTypeOverride-24
  4. whenToUseGet-7
  5. Issues walk-through

2.1 abstractComponentRefs-37

[Ian]

DO: Most updates based on comments from RF. RF expressed a preference. I think there's a dependency on opacity issue.
TB: Procedurally, it seems that we now have enough material to bite down and see what we think. Put this on top of queue at future meeting.
PC: Do any requirements meet needs of WSDL group?
DO: I've not asked them for review.
TB: When we discuss this, they should let us know in advance of our teleconf.
Action DO: Point Jonathan Marsh at options. Ask them for their analysis.

2.2 Architecture document

Update: 23 June 2003 Editor's Draft of the Arch Doc.

  1. Action RF 2003/06/02: Rewrite section 5. Section 5 is expected to be short. See RF placeholder

    TB notes that even if no further text is provided by RF, TB is ok to go to last call with placeholder.

  2. Action CL 2003/06/02: Make available a draft finding on content/presentation.
  3. Action SW 2003/06/02: Continue work on and make available a draft finding related to the opacity of URIs.
  4. Action DO 2003/06/02: Write up a couple of paragraphs on extensibility for section 4.
  5. Action IJ 2003/06/16: Attempt to incorporate relevant bits of "Conversations and State" into section to be produced by RF.
  6. Action PC 2003/06/16: Send second draft of AC announcement regarding TAG's last call expectations/thoughts and relation to AC meeting feedback.

    PC: I expect to send DO a revision.

[Ian]

IJ: Where we on arch doc? Ready to go to TR page?
DC: If it's good enough for IJ and two readers, good enough for me to go to TR page.
TB: I promise to read by Thurs and publish an opinion as to going to TR.
DC: I also commit to reading it.
PC, DO, NW: That plan sounds good.
NW: I may read the arch doc this week.
DC: I think we don't know where TBL is on this. I think he would not object to publishing.
SW: Therefore, with approval from DC, IJ, and TB on 23 June draft, IJ can request publication as TR document.
[Norm]
Ian: wrt 3.2.4 in the new draft, I had intended the two SHOULD paragraphs to be good practice (or some other sort of) notes
[DanC]
so RESOLVED.
[Stuart]
indeed

2.3 contentTypeOverride-24, "Client Handling of MIME Headers"

Numbered points in discussion below are those in summary of comments.

[Ian]

3) I think the finding should address issues of "local override"of headers. Some examples where instructions in content
seem to override headers (if so, why ok? if not, why not?).
- xml:lang
- SCRIPT/type in HTML
- Mixed content
TB: I think that it's ok, once you're inside content, to have extra metadata to help process a particular chunk of the content. xml:lang would have no interpretation if the whole content were served as text/plain. The default toplevel context is that headers are authoritative for the entity as a whole.
IJ: what about xml:lang on the document root?
TB: Won't have meaning unless the media type defines the interpretation.
DC: This is not overriding, this is specializing.
[Discussion of xml:lang; predefined but not required by xml 1.*]
4) We should include a comment that the SMIL 1.0 Recommendation (and possibly others?) does not do the right thing in this area.
TB, DC: Yes.
4) Also, in HTML 4.01, META/http-equiv can be used by servers to generate an HTTP header (see section 7.4.4 [7], subsection
"META and HTTP headers"). This might be a source of confusion because the META element is supposed to be interpreted
server-side, not client-side.
DC: Yes, deal with that. Oh, the finding already does.
[Done]
DC: Let's try to get through this discussion with 0 bytes changes.
5)Add note about use of RFC2119 terms, Sugested tweaking language around "engaging in non-authoritative behavior" in section 4.
[Those two done]
5)Need to talk up security issues that can occur when headers not respected.
PC: Yes, I think we should. This is a compelling argument.
DC: I think there's a CERT Advisory over this...can't remember... If your firewalls say "Keep out all postscript" and this is labeled as "text/plain", and the client peeks in and says "this looks like postscript", then the client has violated firewall rules.
Action TB: Ask www-tag for info about security whole related to contentTypeOverride.
6) From Roy at the 12 May teleconf: Roy cited "efficiency" as a reason why the architecture makes server headers
authoritative. The draft finding does not make the efficiency argument and probably should.
IJ: Efficiency argument is that less costly to examine short string than to look into content.
TB: Notably to fire up an xml parser. It's substantially more costly to dispatch on metadata than on examination inside content.
PC: There's a trade-off between performance and usability.
TB: Arch args on performance and security are pretty high. The CERT Advisory looks very good.
Summarizing: IJ expects to revise finding to take account:
1) Editorial request from E. R. Harold
2) SMIL 1.0 gets it wrong
3) A security scenario
4) Efficiency argument.
Action IJ: Update finding early this week.
DC: Let's not finalize before we meet with Voice WG again. I suggest that we go back to the Voice WG to say we're pretty close on this.
SW: I'll be talking with IJ and the Voice folks on this.
DC: If we invite them to a teleconf, I'd like them to come prepared having read this finding.

Action SW: Work with Voice WG on revised text related to contentTypeOverride-24 and bring back to TAG.

2.4 whenToUseGet-7, "URIs, Addressability, and the use of HTTP GET and POST"

[Ian]
http://lists.w3.org/Archives/Public/www-tag/2003May/0067
http://lists.w3.org/Archives/Public/www-tag/2003May/0066.html
"I think that at this time, Ian's summary is actually more accurate of the
current state of affairs. That is, GET is supported, without RPC vs non-rpc
invoke styles being referenced.
"
DO: There's a difference between RPC generally and the way that SOAP uses the term RPC. I think we are niggling a bit on the exact overlap. I need to refresh my memory on this.
IJ: See also Larry Masinter comments
[DanC]
Regarding LM's comments, "data" or "ftp" would work.
[Ian]
DC: LM is asking us to answer when HTTP is the answer or when any URI would work.
TB: LM's point is well-taken. We should be specific about whether we are talking just about HTTP or a larger class.
IJ: I think a sentence will do.
Action IJ: Incorporate a sentence about scope based on LM comments.

2.5 Issues walk-through

The TAG discussed the following issues with these questions in mind:

  1. Do we need to resolve this issue before going to last call?
  2. How close are we to closing this issue?
  3. Should we spend time on this issue at the upcoming face-to-face meeting?

[Ian]

DC, TB: Not required to complete for last call.
TB: I'm more convinced this is hard and important.
DC: The Arch has grown without this feature and an arch doc can talk about web that precedes this issue.
TB: I agree with DC.
[Support for addressing this issue face-to-face]
DC: Put issues 37 and 38 nearby
* DO: Monitor WSDL WG. See WSDL Reqs, Req#128
DC: I think issue 7 needs to be closed before last call
WSDL spec currently doesn't hurt or help w.r.t this issue.
PC: DO could remind WSDL working group at last call.
TB: You won't leave the room in Vancouver until closed.
PC: Are issues 8 and 35 related?
TB: I can speak to that.
DC: I don't have an expectation that we'll close issue 8 any time soon.
TB summarizing what he thinks necessary to declare victory (1) revised rddl (2) finding citing rddl as one option (3) mapping to RDF
PC: I agree with TB's view of history. Please make required reading the thread that starts with publication of TB's latest version.
TB: Jonathan Borden was agreeing with DC. I would grumble but wouldn't stand in the way. I think it's good to have a statement about canonical RDF to generate. Someone contributed an xslt script.
DC: We didn't end up discussing this at last W3C/IETF meeting for a number of reasons.
TB: I don't think this issue stands in the way of the arch doc
DC: If we're not going to resolve this one, we need to stay clear of it.
[IJ modified doc to address DC's concern]
TB: If RF and TBL don't think we need to resolve this before moving I'm ok to move forward without resolving it.
PC: How do we expect to make progress on this?
TB: This issue is important, but not currently actively affecting the arch doc.
NW: I don't object to leaving it off the agenda of this ftf meeting. But I do not believe we will make substantive progress on this issue except at a face-to-face meeting.
SW: Sounds like we will not discuss httpRange-14 at this upcoming ftf meeting.

3. Not discussed

3.1 New issues? (10 mins)

  1. Summary from Stuart
  2. Completed action IJ 2003/06/16: Add issue putMediaType-38 to issues list.

3.2 Findings

See also: findings.

Next steps for draft findings:

Action IJ 2003/06/09: Turn TB apple story into a finding.

IJ: Not done; some of this in arch doc now, however.

3.3 Issues that have associated action items

4. Other actions

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/06/24 13:41:48 $