W3C | TAG | Previous: 5 May teleconference | Next: 2 June 2003
teleconf
Minutes of 12 May 2003 TAG teleconference
Nearby: IRC log |Teleconference details · issues list · www-tag archive
1. Administrative (45min)
- Roll call: From TAG: SW (Chair), TBL, DC, TB, RF, CL, PC, NW, IJ. For
discussion with Voice WG, DO present. From Voice WG: Scott McGlashan,
Jerry Carter, Brad Porter, Dan Burnett, David Burke, Max Froumentin
- Accepted 5 May teleconference
minutes
- Accepted this agenda
- Next meeting: 2 June [19 June people at AC meeting, 26
May is a holiday in UK/US/Canada].
1.1 Meeting planning
SW: I think we should focus on the arch doc at the 2 June meeting.
PC: There are two kinds of analysis we could do in walking through the
document. Things that people don't agree with.
1.2 W3C Track Presentation
The TAG expects to discuss the report by email.
1.3 TAG report at AC meeting
- Suggestions
for TAG presentation at May AC Meeting from DO and PC
- Action DO, CL: Present TAG's AC meeting report to TAG.
The TAG expects to discuss the presentation/slides by email.
[Ian]
- See comments
from David to TAG
- CL: Important issues that are slowing us down
- [On httpRange-14]
- SW: TimBL and RF have you made progress on your discussions on
httpRange-14?
- RF: Haven't discussed since Irvine face to face meeting. I've been
working on RFC2396, focusing on being able to answer questions
there.
- [On IRI spec]
- RF: At IETF meeting, I thought that we had made a decision. But
Martin re-opened it in light of TAG discussion.
- PC: I think the TAG should report the collateral work that's going on
(e.g., working with IETF)
- RF: Definitely We are updating the primary specs of the Web in
response to some of the issues that have been raised/addressed. We
removed registered name production from the syntax in RFC2396. All of
the names we were using were DNS anyway. That was interfering with IRIs
ability to know SCRIBE MISSED]. ] That was an obstacle to IRI-URI-IRI
conversion.
- TBL: The TAG's primary issue (remaining) has to do with the
namespaces spec.
- CL: Other issues holding us up: Comparison of URIs.
- PC: IRI-Everywhere precedence: RFC2396, IRI spec, then other specs
can then refer to it. Dependencies among specs seems to be a good thing
to bring up.
- CL: Before RFC2396, add IDNS. First half of slides would be to:
- introduce TAG
- TAG generalities
- New issues since last 6 months.
- Issues closed, declined, or pending since last 6 months.
- PC: What about RDDL progress?
- TB: I'm behind on this. What needs to happen is (1) TB needs to clean
up document. (2) PC needs to write up finding.
- [timbl_]
- I commend Tim Bray on his blog on iTunes and WWW architecture.
- [Ian]
- TB: Issue of how to turn RDDL into RDF needs to be solved. If I
commit to do this by the end of this month...
- PC: Agreement to publication of RDDL as Note, then ask AC what to do.
Report to AC that we are behind schedule. I'd suggest adding
namespaceDocument-8 to list of issues to discuss; ask for feedback from
AC on what to do with a RDDL Note. Important question for me is: "How
to proceed with RDDL Note? What model to use?"
- SW: Another piece of work we've stalled on is xlinkScope-23.
- TB: Reminder, we agreed that, since sufficient interest, that we
would agree to revisit the issue and express our technical opinion
again.
- IJ: I read recent XHTML 2.0 draft, section 12.1 on linking. No HLink;
just a comment about the HTML WG following work in this area.
- PC: I think we'd be delinquent not to have xlink-23 on our list.
"Further work pending ....." So for me important issues are: IRI,
HTTPRange, namespace 8, xlinkScope-23. I am concerned about asking
question of last call to AC....
- TBL: I'm concerned about the question regarding last call. E.g., I
feel that we address everything that's happened, not restraining
ourselves to things that happened 2 years before we started. Reasonable
to ask us to publish what we the TAG have now. But I don't want us to
be constrained to just old stuff; people are asking us all the time how
Web Services fit with the Web Architecture; we need to address that. If
we talk about a service-oriented Web and a REST-oriented Web, to talk
about one without the other is crazy. The document should at least make
the distinction. Sem Web / Web Services are not out-of-scope. The issue
of httpRange-14 cannot be resolved without considering the Semantic
Web. I don't think we will have done the world a favor if we publish
something that doesn't take into account Sem Web / Web Services.
- RF: I have no problem with that; it's easier for me if we are talking
about the future Web as well. Then I can bring it all together in the
description.
- PC: We could produce a last call document this fall, but it would
largely be focused on Web today, and weak in other areas. We could ask
the AC whether we could take that to Rec with such a weakness, or
should rather fix before we go to Rec.
- CL: Right, to what extent is it modular?
- IJ: I agree with PC in that, like the Process Doc, it may be a
rolling document. I think we should think about reporting less to the
AC now, and in June addressing the question of last call in more
detail.
2. Technical (45min)
The TAG and Voice Browser Working Group are meeting this week to
discuss this issue.
- [Ian]
- SM: I'd like to give the background of how the Voice WG got to where
it is. See also background
email from SM
- [History: Those present agree to leave history out of public
record.]
- Now looking at:
- http://lists.w3.org/Archives/Public/www-voice/2003JanMar/0062.html
- SM: There are cases where there's a mismatch between the "type"
attribute value and the server config. See also precedence in SMIL
spec.
- [Question of whether SVG does the same thing]
- SM: Question of proper server configurations
- [Chris]
- or perhaps, standardisable server config so authoring tools can help
out
- [Ian]
- SM: We modified the spec in a not-yet-published draft to say that (1)
the protocol override only takes place when the media type returned by
the server is not recognized by the grammar processor as a recognized
grammar type. We'd like architectural consistency, but need to address
real-world server misconfigurations.
- TBL: What about the type application/xml?
- SM: That means nothing to a grammar processor.
- TB: Is there a registered mime type?
- SM: We are in the process of registering three "+xml" types..
- TB: It seems to me to fair to say that this problem is not unique to
this activity. Hints appear as far back as HTML. Is there some way in
which this problem is unique to your application?
- SM: I think you are right, this is a general problem. One thing that
is special is that the grammar processor is not necessarily a user
agent; it can be a background process.
- CL: So there may not be a way to consult the user.......
- SM: Right, consulting the user may not make a lot of sense.
{Scribe missed comment from Jerry Carter here}
- TB to RF: I have heard people say that disregarding media types may
have substantial security implications. I think the finding should say
more about the security issues.
- RF: The way that systems work for filtering content through
enterprises: processing meta information and processing content. You
can either take the approach that meta information is advisory, or that
where the meta information disagrees with the information in the
message is a trust breach. Thus, there are issues of trust and
efficiency.
- SM: What components enforce this policy [when there's a mismatch
between representation and metadata that was declared]?
- [timbl]
- (RF: .... and so when there is a mismatch you can block the data)
- [Ian]
- RF: That's simply a possibility the software can take to avoid trust
issues. The processor could also examine all content and throw away bad
stuff. If you don't tell the system what you're doing with the
information, you run into issues of whether the content is to processed
as part of your grammar. The user agent that's following the reference
can distinguish the two, but intermediaries can't.
- BP: To see whether I get this, let's consider example of proxy.
Suppose Flash content has security breach. You want to disable entry of
flash content into the network. You don't want someone to be able to
put up a Web page that references flash content and that overrides the
security filter. The place where people in the middle can't do anything
is by using HTTPS.
- CL: Suppose you have a document with Japanese mislabeled as
text/plain, and an intermediary does the wrong thing with it due to
misinterpretation of mime type.
- TB: [On dealing with poorly configured Web servers] I understand the
problem, but I'm nervous about what you want to do.
- This application (voice browser) is not unique in having this
problem
- Efficiency gains by being able to dispatch reliably on media type
(rather than look into content) is huge [especially for busy
servers]. Thus, potential efficiency losses are pretty severe.
- There is a new rubric of software (Web services security) where
there will be a high volume of messages exchanged.
- TB: To work properly, this will rely on servers labeling things in a
standards-conformant way. I don't think there's much benefit for
working around a few misconfigured servers.
- SM: I think, in an ideal world, we'd like this. Whose authority do
you take, the author or the server manager?
- [Zakim]
- timbl, you wanted to mention another example of security breach, in
which a file is made which is valid under two grammars. and to say that
on a larger scale allowing override is architecturally a very bad
precedent.
- [Ian]
- TBL: The Web architecture says whose the authority over the URI. A
combination of host manager and author. There's a private arrangement
between the two. The "publisher" (combination of two) is authoritative.
It's damaging to change that. To go this way, in the long term, is
damaging because it undermines the URI as a singleton. You would end up
needing a pair everywhere. We have to defend this fundamental arch
principles.
- [timbl]
- 1) it is early days now - new mime types to become known with time.
it will get better. 2) One can do stuff in the meantime - dispatching
on XML namespace is architecturally very sound.
- [Ian]
- TBL: After a while, people will fix their servers to serve the right
media type, if not immediately. So the question is: How can we fix the
short term problem?
- [Chris]
- out of the box servers know about PNG (after7 years!) but not svg,
yet ...
- [TBray]
- Apache 2 out of the box has SVG I think
- [Chris]
- cool
- [Ian]
- TBL: It is sound to look at the toplevel namespace.
- SM: That's where the authority of the author is encoded.
- [Chris]
- authority of author (ns decls) as opposed to server
- [Ian]
- SM: I'm not talking about general snooping; just a real
representation of the author's intention.
- TBL: But it connects completely if you can get your host to send a
.xml as "application/xml"; in that case it's ok to peak into it.
- TB: Even though it's less efficient. Don't start up an xml parser for
every xml message that comes through.
- [Zakim]
- Chris, you wanted to say this is the passive labelling vs active
processing model dilemma and to talk instead about how unstandardised
control of labelling metadata is the real issue.
- [Ian]
- CL: There is no standardized way for author to locally set up server
for a particular representation. If there were a standardized way to do
this (here's my data and my metadata), then authoring tools could do
the right thing. A kind of standardized ".htaccess" file.
- [Chris]
- we seem to be agreeing its ok to peek at ns in application/xml to
figure out what it is
- [Ian]
- TBL: Looking at namespace is possible short-term solution. Can be
used for new applications, and also small apps that don't want to
register mime type.
- [Chris]
- that relates to xmlfunctions-34
- [Ian]
- BP: I see a general trend in this conversation - not just whether
protocol designation is authoritative relative to client, but also
whether object itself is authoritative (v. server message).
- TBL: The Web architecture is not designed that way - the content type
is authoritative.
- SM: Whose authority is definitive?
- DC: The client can't distinguish through bits the author v. the
server manager. In many cases, the conflict is not observable. If you
say plain text at the top, and the document is xml, then that is also
plain text. The server is right by definition; you can't detect the
conflict on the client-side in the general case.
- JC: If you use other protocols, you won't get content type. There's a
reality that you will need a backup in some cases. Whether you want to
extend that to case where mime type is perceived as invalid is the open
question.
- [Zakim]
- TBray, you wanted to agree with TimBL that it's inappropriate for
user-agents to peek&guess
- [Ian]
- TB: Previously damaging behavior was by one browser that peeked
inside HTML, overriding MIME type. There are improperly configured
servers. I think that if you look at the finding, it says that what's
not ok is to silently work around the unexpected media type.
- PC: So how does the client complain?
- TB: Can you preface to the person listing that there's a config
problem?
- BP: In the voice xml case, the user is not necessarily in control of
the configuration of their client. Another point: by saying that the
protocol designation is authoritative, we are implying that
application/xml is only ok for general case; but each vocab that has
it's own processing model should have its own more specific type.
- TBL: I disagree a little; e.g., test applications.
- [DaveO]
- One problem with looking at the namespace name is it doesn't cover
cases where the top element isn't the "owning" element, i.e., an xslt
style sheet that is an xhtml template and the xslt is embedded
within.
- [Ian]
- TBL: I think that there will be a lot of software that dispatches on
namespace.
- TB: You only do that when you don't have a usable media type.
Dispatching on namespace is more expensive than dispatching on mime
type.
- IJ: What are scenarios where the user don't have any input
opportunities?
- BP: Voice browser we implement doesn't have personal profile for
caller. There are cookies for a given call (some config possible on a
per-call basis), but not configuration across multiple calls. So
problem of persistence across sessions.
- [Issues of processing, jumping out of dialog, then back
in]
- JC: I'd like to go back to dispatch discussion. I agree that dispatch
on namespace is more costly. We are trying to introduce a level between
server media type and namespace that is supplied by the author.
- TBL: I don't think we should not ask the user to guide correction.
Are we talking about guessing across XML or guessing about something
that is not XML.
- [Zakim]
- timbl, you wanted to say asking the user is not an option we should
waste our time over IMHO.
- [DanC]
- TimBL said he didn't want to discuss it, not the he didn't want it to
happen (user correction)
- [Ian]
- JC: In deployed systems, we see 2 cases: either XML v. plain text OR
raw octet stream v. proprietary grammar format.
- [Brad]
- want to acknowledge JC's earlier comments that breaking call flow to
ask this question is not easy UI task for voice environment
- [Ian]
- [TBL suggests a security hack whereby content means one thing to
one person and something else to another.]
- [E.g., when parsed per one spec, looks like a pizza order. When
parsed by a more sophisticated parser, knows you are ordering a pizza +
20 years of life insurance.]
- TBL: You are not being consistent about one published meaning of the
document.
- TB: Seems like we have shared appreciation of the issues (safer,
sounder, more efficient to rely on media types). But I think the
finding sets the right tone.
- SM: The spec attempts to provide a last resort fallback. How do you
deal with the conflict in a voice-only scenario; you don't really have
the opportunity to ask the user how to proceed.
- DC: People do things that are counter to specs. As a rule, we don't
change the specs to accommodate this. Why should W3C accommodate this,
unless we think they're doing something good?
- [Ian]
- IJ: I'd like to point out in finding that SMIL gets it wrong. And in
general, I am listening here to figure out how the finding will evolve
in light of this discussion.
- CL: One reason SMIL did this was due to newness of spec.
- RF: I don't agree with that at all. At apache, people send us their
mime types; we update the core list regularly. We update with stuff
that's been registered. People say "We haven't gotten around to
registering our MIME type."
- [Chris]
- and registration is hard. See five-year email archive about trying to
register some types: http://www.geocrawler.com/archives/3/319/1994/
- [Ian]
- SM: Registration process is challenging in practice. Big issue was
that we had to continue to apply pressure on registration folks.
- SW: In 2.2.2 (speech grammar), para 2, could you explain to us again
the expected behavior.
- [DC excused]
- SW: I am confused by the exception sentences. Latest version is
different -
- [SM reads new text for that section in Voice
WG internal draft.]
- JC: Intent is that the media type in the document should take
precedent over introspection.
- SM: The essence is that the use of the type attribute should be
considered a last resort.
- TBL: The phrase "when the information is unusable to the user agent"
is not well-defined. Something may be unusable for one agent but not
another. When you introduce a new format for your grammar, it allows
agents to get confused. If you produce another specification (e.g.,
SG17) and serve it as an SG17 document, and somebody points to your
document and says it's an SG2 document. It works when you test with
your software, but some clients can't use it.
[Scribe didn't get entire scenario]
- TBL: Grammar may have picked it up from a trust resource, and done
the wrong thing as a result.
- IJ: I haven't understood whether this is really a UI issue. I don't
understand the scenarios enough.
- SM: Fine to pop up a prompt when it's your browser, but different
when it's not your user agent in a voice only case (which would destroy
the intent of the voice-only interaction).
- BP: Consider also automated systems, where there are no user
interface components.
- TBL: My understanding of the way these things will work, is, e.g.,
browsing Web site over cell phone, picking up new information. Don't
ask technical questions of user.
- BP: Do people really understand what "REPOST FORM DATA" really
means?
- SW: Even with override, the actual entity returned could not be a
piece of voice grammar. What would happen then? In that case, it would
generate an exception event (for the AUTHOR to handle). E.g., the
author can terminate the call.
- SW: Why would that not also be a sensible way of handling this case?
Is it just a question of frequency of likely occurrences?
- JC: In intermediate cases, yes.
- SM: Authors control documents but not often can't control the mime
types that are being fed out.
- IJ: Is combination of (1) error-handling mechanism and (2)
application/xml sufficient for short term?
- BP: Problem with error-handling mechanism is that it stops
processing. We'd rather have processing continue when the grammar
engine can use the content.
- SW: The more failure is tolerated in silence, the less one can
address the fact that the servers are not producing the proper
metadata. What we don't want to end up in, is a situation where we move
forward with SRGS and then feel we are blocked later on.
- SM: We recognize that what is proposed is not perfectly in line with
Web arch, but the WG thinks it's a reasonable compromise.
- SW: Difference between what apps do and what you write in specs.
- CL: But hiding things doesn't improve interoperability.
- IJ: Would it be possible to terminate transactions when
misconfiguration occurs? (This is one possible way to handle the error.
How the error is handled would depend on the context/application.)
- SM: Yes, that is a fallback scenario.
- IJ: Send back diagnostics.
- CL: Like an ATM - it just shuts down and says "Try another ATM"
- SM: Almost all voice platforms would log the recasting as a
warning.
- CL: Does the spec say anything about logging?
- SM: I think we could add to the spec that there's an expectation that
system log it.
- [Chris]
- expectation of logging clarifies the seriousness of the issue
- different expectation of timeliness to fix, in a corporate
environment
- [Ian]
- IJ: proposal (1) use application/xml for early deployment. (2) In the
spec, say that when mismatch occurs, don't recover silently from error.
Depending on the application, an agent might, for example, prompt the
user for how to proceed, or, in another (e.g., voice-only) setting,
might terminate and log the transaction mishap.
- SM: Would it be permissible to continue without user permission, but
logging?
- JC: The user and voice browser are separated by more distance; user
not interacting with the browser. The issue of how you accept the
message is in the domain of the browser maintainer. Something like:
"Browser must be configurable to either proceed or return error."?
- IJ: How does grammar processor talk to browser?
- SM: Can happen in different ways.
- IJ: Two pieces: (1) grammar processor must signal error (2) browser
needs to get user permission.
- JC: But that interrupts call flow.
- SM: I think that logging would be acceptable to Voice WG. I think the
Voice WG would accept a req to inform provider of mismatch, even if
agent allowed to proceed.
- IJ: Next step?
- SM: We'll discuss tomorrow at mtg. Depending on the meeting, we can
have another discussion.
SW: Perhaps at next meeting, poll TAG for individuals and when they
would meet.
2.2 Architecture document
No discussion this week.
See also: findings.
- 26 Mar 2003
Working Draft of Arch Doc:
- Action DC 2003/01/27: write two pages on correct and incorrect
application of REST to an actual web page design
- Action DO 2003/01/27: Please send writings regarding Web services
to tag@w3.org. DO grants DC license to cut and paste and put into DC
writing.
- Action DC 2003/03/17: : Write some text for interactions chapter of
arch doc related to message
passing, a dual of shared state.
2.3 Issues that have associated action items
- whenToUseGet-7
- 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?]
- abstractComponentRefs-37
- 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.
- Action PC 2003/04/07: Prepare finding to answer this issue,
pointing to the RDDL Note. See comments
from Paul regarding TB theses.
- Action TB 2003/04/28: Draft a TAG opinion on the use of URNs for
namespace names, for review by the TAG
- RF: Folks assume that because the specs say so, URNs will be
persistent. But persistence is a function of institutional
commitment and frequency of use.
- xlinkScope-23
- IRIEverywhere-27
- Completed action TB 2003/04/14: Draft a proposed step forward on
IRI 27. (Done).
In that email,
TB proposes to close this issue.
- 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. Progress: See email
to TAG.
URIEquivalence-15
- SW proposal: Track RFC2396bis where Tim Bray text has
been integrated. Comment within the IETF process. Move this issue to
pending state.
- xmlIDSemantics-32
- siteData-36
- Action TBL 2003/02/24 : Summarize siteData-36
- 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.
- 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.
- contentPresentation-26
- Action CL 2003/02/06: Create a draft finding in this space. Due 3
March.
- rdfmsQnameUriMapping-6
- Action DC 2003/02/06: Propose TAG response to XML Schema
desideratum (RQ-23).
- 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. Relation to Client
handling of MIME headers?
- metadataInURI-31
- fragmentInXML-28
: Use of fragment identifiers in XML.
- Connection to content negotiation?
- Connection to opacity of URIs?
- No actions associated / no owner.
3. 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: 2006/10/20 11:03:41 $