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
- Roll call: SW (Chair), DC, NW, DO, TB, PC, IJ (Scribe).. Regrets: TBL,
RF, CL
- Accepted minutes of 16 Jun
teleconference
- Accepted this agenda
- Next meeting: 30 June. Regrets: PC, DO.
- 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
- abstractComponentRefs-37
- Architecture Document
- contentTypeOverride-24
- whenToUseGet-7
- Issues walk-through
[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.
Update: 23 June
2003 Editor's Draft of the Arch Doc.
- 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.
- Action CL 2003/06/02: Make available a draft finding on
content/presentation.
- Action SW 2003/06/02: Continue work on and make available a draft
finding related to the opacity of URIs.
- Action DO 2003/06/02: Write up a couple of paragraphs on extensibility
for section 4.
- Action IJ 2003/06/16: Attempt to incorporate relevant bits of "Conversations and
State" into section to be produced by RF.
- 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
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.
- [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.
The TAG discussed the following
issues with these questions in mind:
- Do we need to resolve this issue before going to last call?
- How close are we to closing this issue?
- 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.
- namespaceDocument-8
- Action TB 2003/04/07: Prepare RDDL Note. Include in status section
that there is TAG consensus that RDDL is a suitable format for
representations of an XML namespace. Clean up messy section 4 of RDDL
draft and investigate and publish a canonical mapping to RDF. See
TB's 1 June
version.
- Action PC 2003/04/07: Prepare finding to answer this issue,
pointing to the RDDL Note. See comments
from Paul regarding TB theses.
- Refer to draft TAG opinion
from Tim Brayon the use of URNs for namespace names.
- RF: Folks assume that because the specs say so, URNs will be
persisitent. But persistence is a function of institutional
commitment and frequency of use.
- 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.
- uriMediaType-9
- IANA appears to have responded to the spirit of this draft (see email
from Chris Lilley).What's required to close this issue?
- Action CL 2003/05/05: Propose CL's three changes to registration
process to Ned Freed. [What forum?]
- 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)
- Summary
from Stuart
- 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
- URIEquivalence-15
- SW proposal: Track RFC2396bis where Tim Bray text has
been integrated. Comment within the IETF process. Move this issue to
pending state.
- HTTPSubstrate-16
- Action RF 2003/02/06: Write a response to IESG asking whether
the Web services example in the SOAP 1.2 primer is intended to be
excluded from RFC 3205
- See message
from Larry Masinter w.r.t. Web services.
- errorHandling-20
- Action CL 2003/02/06: Write a draft finding on the topic of
(1) early/late detection of errors (2) late/early binding (3)
robustness (4) definition of errors (5) recovery once error has been
signaled. Due first week of March.
- xlinkScope-23
- contentPresentation-26
- Action CL 2003/02/06: Create a draft finding in this space..
- IRIEverywhere-27
- Action CL 2003/04/07: Revised position statement on use of IRIs. CL
says to expect this by 21 April.
- Action TBL 2003/04/28: Explain how existing specifications that
handle IRIs are inconsistent. TBL
draft not yet available on www-tag.
- See TB'sproposed
step forward on IRI 27.
- fragmentInXML-28
: Use of fragment identifiers in XML.
- Connection to content negotiation?
- Connection to opacity of URIs?
- No actions associated / no owner.
- binaryXML-30
- Action TB 2003/02/17: Write to www-tag with his thoughts on adding
to survey.
- Next steps to finding? See summary
from Chris.
- metadataInURI-31
- xmlIDSemantics-32
- xmlFunctions-34
- Action TBL 2003/02/06: State the issue with a reference to XML Core
work. See email
from TimBL capturing some of the issues.
- siteData-36
- Action TBL 2003/02/24 : Summarize siteData-36
4. Other actions
- Action IJ 2003/02/06: Modify issues list to show that actions/pending
are orthogonal to decisions. IJ and PLH making substantial progress on
this; hope to have something to show in May.
Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/06/24 13:41:48 $