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)

  1. 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
  2. Accepted 5 May teleconference minutes
  3. Accepted this agenda
  4. 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

  1. Suggestions for TAG presentation at May AC Meeting from DO and PC
  2. 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:
  1. introduce TAG
  2. TAG generalities
  3. New issues since last 6 months.
  4. 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)

2.1 contentTypeOverride-24

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.
  1. This application (voice browser) is not unique in having this problem
  2. 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.
  3. 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.

  1. 26 Mar 2003 Working Draft of Arch Doc:
    1. Action DC 2003/01/27: write two pages on correct and incorrect application of REST to an actual web page design
    2. 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.
    3. 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

3. Other actions

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2006/10/20 11:03:41 $