IRC log of tagmem on 2003-05-12

Timestamps are in UTC.

18:54:25 [RRSAgent]: RRSAgent has joined #tagmem
18:56:44 [Zakim]: TAG_Weekly()3:00PM has now started
18:56:50 [Zakim]: +TimBL
18:57:30 [Ian]: Ian has joined #tagmem
18:58:12 [Ian]: RRSAgent, start
18:58:14 [Ian]: zakim, this is TAG
18:58:14 [Zakim]: Ian, this was already TAG_Weekly()3:00PM
18:58:15 [Zakim]: ok, Ian
18:58:16 [Ian]: Could somebody op me?
18:58:18 [Ian]: Thank you
18:58:25 [Ian]: zakim, call Ian-BOS
18:58:25 [Zakim]: ok, Ian; the call is being made
18:58:27 [Zakim]: +Ian
18:59:08 [Roy]: Roy has joined #tagmem
19:00:19 [Zakim]: +??P1
19:00:27 [Zakim]: +??P2
19:00:28 [Ian]: zakim, ++P1 is Roy
19:00:28 [Zakim]: sorry, Ian, I do not recognize a party named '++P1'
19:00:35 [Ian]: zakim, ??P1 is Roy
19:00:35 [Zakim]: +Roy; got it
19:00:43 [Ian]: zakim, ??P2 is Stuart
19:00:43 [Zakim]: +Stuart; got it
19:02:02 [Zakim]: +Tim_Bray
19:02:33 [TBray]: TBray has joined #tagmem
19:02:45 [Ian]: zakim, who's here?
19:02:45 [Zakim]: On the phone I see TimBL, Ian, Roy, Stuart, Tim_Bray
19:02:46 [Zakim]: On IRC I see TBray, Roy, Ian, RRSAgent, Zakim, timbl_, Stuart
19:03:02 [Ian]: Regrets: David Orchard.
19:04:12 [DanC]: DanC has joined #tagmem
19:04:20 [Zakim]: +Norm
19:04:21 [Zakim]: -Norm
19:04:37 [Zakim]: +Norm
19:05:51 [Zakim]: +DanC
19:06:19 [DanC]: phpht.
19:06:30 [Zakim]: -DanC
19:06:50 [Ian]: Roll call: TBL, TB, NW, SW, IJ, DC, RF. Regrets: DO
19:06:59 [Zakim]: +DanC
19:07:19 [Ian]: Accepted http://www.w3.org/2003/05/05-tag-summary.html
19:07:25 [Ian]: Agenda:
19:07:38 [Ian]: http://www.w3.org/2003/05/05-tag.html
19:08:13 [Ian]: DO notes: http://lists.w3.org/Archives/Member/tag/2003May/0029.html
19:08:24 [Ian]: Next meeting?
19:08:29 [Ian]: SW: Bank holiday in the UK
19:08:39 [DanC]: 12May, that is
19:08:49 [Ian]: 26 May
19:08:56 [TBray]: Holiday in Canada is 26
19:09:03 [Ian]: Memorial day in US
19:09:12 [Ian]: Missing: CL, PC
19:09:17 [DanC]: never mind my 12May typo
19:09:29 [Zakim]: + +1.301.975.aaaa
19:09:43 [DanC]: 19May conflicts with Budapest AC
19:09:45 [Chris]: Chris has joined #tagmem
19:09:55 [Ian]: zakim, +aaaa is Paul
19:09:56 [Zakim]: +Chris
19:09:57 [Zakim]: sorry, Ian, I do not recognize a party named '+aaaa'
19:10:05 [Ian]: zakim, +1.301 is Paul
19:10:06 [Zakim]: +Paul; got it
19:10:23 [Ian]: Proposed next meeting: 2 June.
19:10:28 [TBray]: Systemic problem of having a meeting on a Monday, we miss all long weekends
19:11:27 [DanC]: Monday meeting suck so many ways.
19:11:37 [Chris]: ;-)
19:11:41 [Ian]: Resolved: Next scheduled meeting 2 June.
19:12:01 [Ian]: SW: We'll have to build agenda by email; 15:00z to 19:00z
19:12:22 [Ian]: [IJ may have gotten that wrong: 10am ET to 2pm ET is what I think the times are]
19:12:40 [Ian]: SW: I think we should focus on the arch doc at the 2 June meeting.
19:13:10 [Ian]: PC: There are two kinds of analysis we could do in walking through the document. Things that people don't agree with.
19:14:59 [Ian]: -----------------------
19:15:06 [Ian]: 1.2 W3C Track Presentation
19:15:06 [Ian]: * Action PC 2003/04/14: Propose TAG's WWW2003 track report to TAG.
19:15:25 [Ian]: PC: I am behind on this; sorry about that. I hope to have something for people to look at this evening.
19:16:06 [Ian]: http://www2003.org/t_www.htm
19:16:15 [Ian]: 30 minutes of 90-minutes slot.
19:16:44 [Ian]: DC: I don't think there's emergency on this.
19:16:49 [Ian]: SW: Ok, we'll have to comment by email.
19:17:50 [Ian]: --------------
19:17:56 [Ian]: AC meeting report [DO and CL]
19:19:00 [Ian]: http://lists.w3.org/Archives/Member/tag/2003May/0029.html
19:19:35 [Ian]: CL: Important issues that are slowing us down
19:20:03 [Ian]: [On httpRange-14]
19:20:15 [Ian]: SW: TimBL and RF have you made progress on your discussions on httpRange-14?
19:20:21 [Ian]: RF: Haven't discussed since Irvine.
19:21:32 [Stuart]: q?
19:21:33 [Ian]: RF: I've been working on RFC2396, focusing on being able to answer questions there.
19:22:00 [Ian]: [On IRI spec]
19:22:47 [Ian]: RF: At IETF meeting, I thought that we had made a decision. But Martin re-opened it in light of TAG discussion.
19:23:43 [Ian]: PC: I think the TAG should report the collateral work that's going on (e.g., working with IETF)
19:23:45 [Ian]: RF: Definitely.
19:23:59 [Ian]: RF: We are updating the primary specs of the Web in response to some of the issues that have been raised/addressed.
19:24:16 [Ian]: RF: We removed registered name production from the syntax in RFC2396.
19:24:45 [Ian]: RF: All of the names we were using were DNS anyway. That was interfering with IRIs ability to know [something]
19:24:54 [Ian]: RF: That was an obstacle to IRI-URI-IRI conversion.
19:25:05 [Ian]: TBL: The TAG's primary issue (remaining) has to do with the namespaces spec.
19:25:41 [Ian]: CL: Other issues holding us up: Comparison of URIs.
19:26:01 [Ian]: PC: IRI-Everywhere precedence: RFC2396, IRI spec, then other specs can then refer to it.
19:27:28 [Ian]: PC: Dependencies among specs seems to be a good thing to bring up.
19:27:37 [Ian]: CL: Before RFC2396, add IDNS
19:28:52 [Ian]: CL: first half of slides would be to:
19:28:57 [Ian]: a) introduce TAG
19:29:11 [Ian]: b) Generalities (pointers to TAG resources)
19:29:20 [Ian]: c) Issues open in last 6 months.
19:30:19 [Chris]: d) issues closed or refused
19:30:41 [Ian]: IJ: I"ve provided this info to the COO; CL please double-check.
19:31:06 [Ian]: PC: What about RDDL progress?
19:31:26 [Ian]: 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.
19:31:27 [timbl_]: I commend Tim Bray on his blog on iTunes and WWW architecture.
19:32:02 [Ian]: TB: Issue of how to turn RDDL into RDF needs to be solved.
19:32:15 [Ian]: TB: If I commit to do this by the end of this month...
19:32:43 [Ian]: PC: Agreement to publication of RDDL as Note, then ask AC what to do.
19:32:49 [Ian]: PC: report to AC that we are behind schedule.
19:33:14 [Ian]: q+
19:33:44 [Ian]: PC: 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.
19:33:59 [Ian]: PC: Top three questions for me:
19:34:05 [Ian]: 1) How to proceed with RDDL Note?
19:34:15 [Ian]: [What model to use?]
19:34:27 [Ian]: SW: Another piece of work we've stalled on is xlinkScope-23.
19:35:09 [Ian]: TB: Reminder, we agreed that, since sufficient interest, that we would agree to revisit the issue and express our technical opinion again.
19:35:53 [Ian]: IJ: I read recent XHTML 2.0 draft, section 12.1 on linking
19:36:29 [Ian]: [No HLink; just a comment about the HTML WG following work in this area.]
19:36:48 [Ian]: PC: I think we'd be delinquent not to have xlink-23 on our list.
19:37:17 [Ian]: PC: "Further work pending ....."
19:37:35 [Ian]: PC: So: IRI, HTTPRange, namespace 8, xlinkScope-23
19:38:04 [Ian]: PC: I am concerned about asking question of last call to AC....
19:38:09 [Ian]: q-
19:39:19 [Ian]: 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.
19:40:03 [Ian]: TBL: 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.
19:40:24 [Ian]: q+ to talk about reporting, not asking.
19:40:47 [Ian]: TBL: If we talk about a service-oriented Web and a REST-oriented Web, to talk about one without the other is crazy.
19:40:52 [Ian]: TBL: The document should at least make the distinction.
19:40:59 [Ian]: TBL: Sem Web / Web Services are not out-of-scope.
19:41:12 [Ian]: TBL: The issue of httpRange-14 cannot be resolved without considering the Semantic Web.
19:41:33 [Ian]: TBL: 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.
19:41:44 [Ian]: RF: I have no problem with that; it's easier for me if we are talking about the future Web as well.
19:41:56 [Ian]: RF: Then I can bring it all together in the description.
19:42:13 [DanB]: DanB has joined #tagmem
19:42:38 [Ian]: 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.
19:42:47 [Ian]: CL: Right, to what extent is it modular?
19:42:49 [Zakim]: +Scott_McGlashan
19:43:21 [Zakim]: +Daniel_Burnett
19:43:48 [DanB]: zakim, Daniel_Burnett is me
19:43:48 [Zakim]: +DanB; got it
19:43:51 [Ian]: q-
19:44:06 [Ian]: IJ: I agree with PC in that, like the Proces Doc, it may be a rolling document.
19:44:33 [Ian]: IJ: I think we should think about reporting less to the AC now, and in June addressing the question of last call in more detail.
19:44:40 [Ian]: =================================
19:44:55 [Ian]: Voice WG discussion
19:45:08 [Ian]: Roll call: Dan Burnett, Scott McGlashan
19:45:38 [Ian]: zakim, who's here?
19:45:38 [Zakim]: On the phone I see TimBL, Ian, Roy, Stuart, Tim_Bray, Norm, DanC, Paul, Chris, Scott_McGlashan, DanB
19:45:40 [Zakim]: On IRC I see DanB, Chris, DanC, TBray, Roy, Ian, RRSAgent, Zakim, Stuart
19:45:40 [Zakim]: +??P8
19:45:48 [Ian]: zakim, ??P8 is Dave Burke
19:45:48 [Zakim]: I don't understand '??P8 is Dave Burke', Ian
19:45:55 [Zakim]: +Jerry_Carter
19:45:59 [maxf]: maxf has joined #tagmem
19:46:00 [Zakim]: +MaxF
19:46:16 [Ian]: Roll call: Dan Burnett, Scott McGlashan, Dave Burke, Jerry Carter, Max Froumentin
19:46:48 [TBray]: Our recent finding: http://www.w3.org/2001/tag/doc/mime-respect.html
19:47:06 [Ian]: [Introductions]
19:47:25 [Ian]: SM: I'd like to give the background of how the Voice WG got to where it is.
19:48:07 [Ian]: [History]
19:48:36 [Ian]: [Those present agree to leave history out of public record.]
19:48:47 [timbl]: timbl has joined #tagmem
19:49:19 [Ian]: Background: http://lists.w3.org/Archives/Member/tag/2003May/0012.html
19:49:35 [Ian]: [This is on SRGS]
19:49:40 [maxf]: SRGS: http://www.w3.org/TR/speech-grammar/
19:49:54 [DanC]: "back up"? what are we looking at?
19:50:07 [Ian]: We were looking at:
19:50:19 [Ian]: http://lists.w3.org/Archives/Member/tag/2003May/0012.html
19:50:21 [DanC]: thx.
19:50:22 [Ian]: Now looking at:
19:50:29 [Ian]: http://lists.w3.org/Archives/Public/www-voice/2003JanMar/0062.html
19:51:09 [Ian]: SM: There are cases where there's a mismatch between the "type" attribute value and the server config.
19:51:26 [Ian]: SM: See also precedence in SMIL spec.
19:51:44 [Ian]: [Question of whether SVG does the same thing]
19:51:58 [Ian]: SM: Question of proper server configurations
19:52:32 [Chris]: or perhaps, sanndardisable server config so authoring tools can help out
19:52:36 [Ian]: SM: We modified the spec 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 valud media type.
19:53:03 [Zakim]: +??P10
19:53:20 [DanB]: correction: "valid media type" should say "recognized grammar type"
19:54:01 [Ian]: SM: We'd like architectural consistency, but need to address real-world server misconfigurations.
19:54:14 [Ian]: TBL: What about the type application/xml?
19:54:21 [Ian]: SM: That means nothing to a grammar processor.
19:54:37 [Ian]: TB: Is there a registered mime type?
19:54:39 [Ian]: SM: That's in process.
19:54:56 [Ian]: SM: There are three in consideration.
19:55:08 [Ian]: SM: These are being registered as "+xml" types.
19:55:20 [Ian]: Joined the call: Brad Porter
19:55:31 [Ian]: q?
19:55:46 [Ian]: TB: It seems to me to fair to say that this problem is not unique to this activity.
19:55:54 [timbl]: Zakim, ??P10 is BradPorter
19:55:54 [Zakim]: +BradPorter; got it
19:56:12 [Ian]: TB: Hints appear as far back as HTML.
19:56:28 [Ian]: TB: Is there some way in which this problem is unique to your application?
19:56:55 [Ian]: 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.
19:57:00 [Zakim]: + +49.894.aabb
19:57:06 [Ian]: CL: So there may not be a way to consult the user.......
19:57:13 [Ian]: SM: Right, consulting the user may not make a lot of sense.
19:57:31 [Ian]: zakim, +49 is David
19:57:31 [Zakim]: +David; got it
19:57:39 [DanB]: ian: last speaker was Jerry Carter
19:57:48 [Ian]: s/SM/JC
19:57:56 [DanB]: (no, i mean after Scott. sorry)
19:58:06 [Ian]: TB to RF: I have heard people say that disregarding media types may have substantial security implications.
19:58:21 [Ian]: TB: I think the finding should say more about the security issues.
19:58:51 [Ian]: RF: The way that systems work for filtering content through enterprises: processing meta information and processing content.
19:59:22 [Ian]: RF: 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.
19:59:40 [Ian]: RF: Thus, there are issues of trust and efficiency.
20:00:01 [Ian]: SM: What components enforce this policy?
20:00:14 [Ian]: [When there's a mismatch between representation and metadata that was declared.]
20:00:33 [timbl]: (RF: .... and so when there is a mismtach you can block the data)
20:00:48 [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.
20:01:18 [TBray]: q+
20:01:20 [Ian]: RF: 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 gramm.
20:01:24 [Ian]: s/gramm/grammar
20:01:40 [Ian]: RF: The user agent that's following the reference can distinguish the two, but intermediaries can't.
20:01:49 [DanB]: brad porter
20:02:32 [Ian]: BP: 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.
20:02:45 [Ian]: BP: The place where people in the middle can't do anything is by using HTTPS.
20:02:57 [Stuart]: q?
20:03:06 [timbl]: q+ to mention another exapmle of security breach, in which a file is made which is valid under two grammars.
20:03:30 [Chris]: q+ to say this is the passive labelling vs active processing model dilemma
20:03:35 [Ian]: 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.
20:04:04 [DaveO]: DaveO has joined #tagmem
20:04:05 [timbl]: q+ to say that on a larger scale allowing override is architecturally a very bad precedent.
20:04:19 [Ian]: ack TBray
20:04:34 [Brad]: Brad has joined #tagmem
20:04:51 [Ian]: TB: [On dealing with poorly configured Web servers] I understand the problem, but I'm nervous about what you want to do.
20:05:29 [Ian]: TB: (1) This application 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].
20:06:04 [Ian]: TB: Thus, potential efficiency losses are pretty severe. (3) There is a new rubrique of software (Web services security) where there will be a high volume of messages exchanged.
20:06:24 [Ian]: TB: To work properly, this will rely on servers labeling things in a stds-conformant way.
20:06:50 [Ian]: TB: I don't think there's much benefit for working around a few misconfigured servers.
20:07:05 [Ian]: SM: I think, in an ideal world, we'd like this.
20:07:05 [Ian]: q?
20:07:22 [Ian]: SM: Whose authority do you take, the author or the server manager?
20:07:30 [Ian]: ack timbl
20:07:30 [Zakim]: timbl, you wanted to mention another exapmle 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
20:07:33 [Zakim]: ... architecturally a very bad precedent.
20:08:04 [Ian]: TB: 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.
20:08:24 [Ian]: TB: The "publisher" (combination of two) is authoritative. It's damaging to change that.
20:08:32 [Ian]: s/TB/TBL above comments.
20:08:51 [Chris]: q+ to talk instead about how unstandardised control of labelling metadata is the real issue
20:08:54 [Ian]: TBL: 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.
20:09:06 [Ian]: TBL: We have to defend this fundamental arch principles.
20:09:13 [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.
20:09:39 [Ian]: TBL: After a while, people will fix their servers to serve the right media type, if not immediately.
20:10:02 [Ian]: TBL: So the question is: How can we fix the short term problem?
20:10:24 [Chris]: out of the box servers know about PNG (after7 years!) but not svg, yet ...
20:10:53 [TBray]: Apache 2 out of the box has SVG I think
20:10:58 [Chris]: cool
20:11:00 [Ian]: TBL: It is sound to look at the toplevel namespace.
20:11:09 [Ian]: SM: That's where the authority of the author is encoded.
20:11:26 [Chris]: authority of author (ns decls) as opposed to server
20:11:31 [Ian]: SM: I'm not talking about general snooping; just a real representation of the author's intention.
20:11:54 [Stuart]: q?
20:11:57 [Ian]: TBL: But it connects completely if you can get your hoster to send a .xml as "application/xml"; in that case it's ok to peak into it.
20:12:02 [Ian]: TB: Even though it's less efficient.
20:12:14 [Ian]: TB: Don't start up an xml parser for every xml message that comes through.
20:12:17 [Ian]: ack Chris
20:12:17 [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
20:12:20 [Zakim]: ... issue
20:13:12 [Ian]: CL: There is no standardized way for author to locally set up server for a particular representation.
20:13:39 [Ian]: CL: 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.
20:13:41 [Brad]: q+
20:13:51 [Chris]: we seem to be agreeing its ok to peek at ns in application/xml to figure out what it is
20:14:01 [Ian]: TBL: Looking at namespace is possible short-term solution.
20:14:13 [Ian]: TBL: Can be used for new applications, and also small apps that don't want to register mime type.
20:14:33 [Chris]: that relates to xmlfunctions-34
20:14:47 [Stuart]: ack Brad
20:14:47 [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).
20:15:11 [Ian]: TBL: The Web architecture is not designed that way - the content type is authoritative.
20:15:37 [Zakim]: -Norm
20:15:37 [Ian]: SM: Whose authority is definitive?
20:15:48 [Ian]: DC: The client can't distinguish through bits the author v. the server manager.
20:16:02 [TBray]: q+ to agree with TimBL that it's inappropriate for user-agents to peek&guess
20:16:21 [Ian]: DC: 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; the client can't tell the difference.
20:16:31 [Ian]: DC: You can't detect the conflict on the client-side.
20:16:37 [DanC]: (in the general sense)
20:16:42 [DanC]: (general case)
20:16:46 [Stuart]: ack Jerry_Carter
20:17:09 [Ian]: 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.
20:17:20 [Brad]: q+
20:17:26 [Ian]: JC: Whether you want to extend that to case where mime type is perceived as invalid is the open question.
20:17:33 [Stuart]: ack TBray
20:17:33 [Zakim]: TBray, you wanted to agree with TimBL that it's inappropriate for user-agents to peek&guess
20:18:09 [Ian]: TB: Previously damaging behavior was by one browser that peeked inside HTML, overriding MIME type.
20:18:32 [Ian]: TB: 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.
20:18:54 [Ian]: PC: So how does the client complain?
20:19:02 [Ian]: q+
20:19:19 [Ian]: TB: Can you preface to the person listing that there's a config problem?
20:19:24 [Ian]: ack Brad
20:19:40 [Ian]: BP: In the voice xml case, the user is not necessarily in control of the configuration of their client.
20:20:25 [Ian]: BP: 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.
20:20:34 [Ian]: TBL: I disagree a little; e.g., test applications.
20:20:50 [DaveO]: One problem with looking at the namespace name is it doesn't cover cases where the top element isn't the "owning" element, ie an xslt style sheet that is an xhtml template and the xslt is embedded within.
20:21:08 [Ian]: TBL: I think that there will be a lot of software that dispatches on namespace.
20:21:17 [Chris]: q?
20:21:29 [Ian]: 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.
20:22:28 [timbl]: q+ to say asking the user is not an option we should waste our time over IMHO.
20:22:29 [Ian]: IJ: What are scenarios where the user don't have any input opportunities?
20:22:51 [Stuart]: ack Ian
20:23:12 [Ian]: 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.
20:23:29 [Ian]: BP: So problem of persistence across sessions.
20:23:40 [Roy]: Roy has left #tagmem
20:24:19 [Stuart]: q?
20:24:20 [Ian]: [Issues of processing, jumping out of process, then back in]
20:24:25 [Ian]: ack Jerry Carter
20:25:04 [Ian]: 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.
20:25:24 [Ian]: TBL: I don't think we should not ask the user to guide correction.
20:25:55 [Stuart]: q+
20:25:57 [Ian]: TBL: Are we talking about guessing across XML or guessing about something that is not XML.
20:26:04 [Stuart]: ack timbl
20:26:04 [Zakim]: timbl, you wanted to say asking the user is not an option we should waste our time over IMHO.
20:26:07 [DanC]: TimBL said he didn't want to discuss it, not the he didn't want it to happen (user correction)
20:26:34 [Ian]: JC: In deployed systems, we see 2 cases: either XML v. plain text OR raw octet stream v. proprietary grammar format.
20:26:39 [Brad]: want to acknowledge JC's earlier comments that breaking call flow to ask this question is not easy UI task for voice environment
20:27:05 [Ian]: [TBL suggests a security hack whereby content means one thing to one person and something else to another.]
20:27:31 [Ian]: [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.]
20:27:40 [Ian]: TBL: You are not being consistent about one published meaning of the document.
20:27:46 [Ian]: [We have bridge for 30 more minutes]
20:27:49 [Ian]: q?
20:27:59 [Stuart]: q-
20:28:04 [Ian]: TB: Seems like we have shared appreciation of the issues (safer, sounder, more efficient to rely on media types).
20:28:33 [Zakim]: +TimBL.a
20:28:38 [Zakim]: -TimBL
20:28:40 [Ian]: TB: But I think the finding sets the right tone.
20:28:57 [Ian]: q+ to talk about finding
20:29:12 [Ian]: SM: The spec attempts to provide a last resort fallback.
20:29:31 [Zakim]: -Tim_Bray
20:29:34 [TBray]: later guys
20:29:47 [Ian]: SM: 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.
20:29:50 [Ian]: q-
20:30:26 [Ian]: DC: People do things that are counter to specs. As a rule, we don't change the specs to accommodate this. Why should W3C endorse the practice of doing something else?
20:31:09 [DanC]: ... accomodate this, unless we think they're doing something good.
20:31:09 [Ian]: IJ: I'd like to point out in finding that SMIL gets it wrong.
20:31:30 [Zakim]: -TimBL.a
20:31:43 [Ian]: CL: One reason SMIL did this was due to newness of spec.
20:31:47 [Ian]: RF: I don't agree with that at all.
20:32:00 [Ian]: RF: At apache, people send us their mime types; we update the core list regularly.
20:32:20 [Zakim]: +TimBL
20:32:22 [Ian]: RF: We update with stuff that's been registered. People say "We haven't gotten around to registering our MIME type."
20:32:42 [Chris]: and registration is hard
20:32:45 [Ian]: SM: Registration process is challenging in practice.
20:33:19 [Stuart]: ack DanC
20:34:30 [Ian]: SM: Big issue was that we had to continue to apply pressure on registration folks.
20:34:58 [Ian]: SW: In 2.2.2 (speech grammar), para 2, could you explain to us again the expected behavior.
20:35:27 [Ian]: [DC excused]
20:35:29 [Zakim]: -DanC
20:35:40 [Zakim]: -Roy
20:35:44 [Ian]: SW: I am confused by the exception sentences.
20:35:52 [Ian]: SM: Latest version is different -
20:36:07 [Chris]: http://www.geocrawler.com/archives/3/319/1994/
20:36:24 [Chris]: fivew year email archive about trying to register some types .....
20:36:27 [Ian]: [New text]
20:36:50 [Zakim]: -David
20:37:31 [Ian]: JC: Intent is that the media type in the document should take precedent over introspection.
20:37:46 [Ian]: SM: "Use of type attribute should be considered a last resort."
20:37:54 [Ian]: zakim, unmute TimBL
20:37:54 [Zakim]: TimBL was not muted, Ian
20:38:30 [Ian]: TBL: The phrase "unusable" is not well-defined. Something may be unusable for one agent but not another.
20:38:44 [Ian]: TBL: When you introduce a new format for your grammar, it allows agents to get confused.
20:38:55 [Stuart]: q?
20:39:50 [Ian]: TBL: 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.
20:39:52 [Brad]: I believe this is the internal draft Scott referenced: http://lists.w3.org/Archives/Member/w3c-voice-wg/2003Apr/0136.html
20:40:08 [Ian]: TBL: Grammar may have picked it up from a trust resource, and done the wrong thing as a result.
20:41:50 [Brad]: q+
20:42:12 [Ian]: IJ: I haven't understood whether this is really a UI issue. I don't understand the scenarios enough.
20:42:55 [Ian]: 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).
20:43:43 [Ian]: BP: Consider also automated systems, where there are no user interface components.
20:43:47 [Zakim]: -Paul
20:43:51 [Brad]: q-
20:43:56 [Ian]: ack TimBL
20:45:16 [Ian]: 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.
20:45:19 [Stuart]: q+
20:45:38 [Ian]: Do people really understand what "REPOST FORM DATA" really means? :)
20:45:50 [Ian]: {that comment not from IJ, I think from BP}
20:46:07 [Ian]: SW: Even with override, the actual entity returned could not be a piece of voice grammar. What would happen then?
20:46:32 [Ian]: SM: In that case, it would generate an exception event (for the AUTHOR to handle).
20:46:38 [Ian]: SM: E.g., the author can terminate the call.
20:46:57 [Ian]: SW: Why would that not also be a sensible way of handling this case? Is it just a question of frequency of likely occurrences?
20:47:04 [Ian]: JC: In intermediate cases, yes.
20:47:20 [Ian]: SM: Authors control documents but not often can't control the mime types that are being fed out.
20:48:05 [Stuart]: q?
20:48:11 [Stuart]: q-
20:48:13 [Ian]: IJ: Is combination of (1) error-handling mechanism and (2) application/xml sufficient for short term?
20:48:34 [Ian]: 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.
20:48:41 [Brad]: unfortunately, I must drop off. ian, thank you for setting up this discussion; it is important for building strong intrateam relationships!
20:48:46 [Zakim]: -BradPorter
20:49:02 [Ian]: Thanks for helping, Brad.
20:49:41 [Ian]: zakim, who's here?
20:49:41 [Zakim]: On the phone I see Ian, Stuart, Chris, Scott_McGlashan, DanB, ??P8, Jerry_Carter, MaxF, TimBL (muted)
20:49:43 [Zakim]: On IRC I see Brad, maxf, DanB, Chris, DanC, Ian, RRSAgent, Zakim, Stuart
20:49:44 [Zakim]: -TimBL
20:50:10 [Ian]: SW: The more failure is tolerated in silence, the less one can address the fact that the servers are not producing the proper metadata.
20:51:33 [Ian]: SM: 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.
20:53:02 [Ian]: SM: We recognize that what is proposed is not perfectly in line with Web arch, but the WG thinks it's a reasonable compromise.
20:53:57 [Ian]: q+ to pursue bank interaction with lady.
20:54:13 [Ian]: SW: Difference between what apps do and what you write in specs.
20:54:44 [Ian]: CL: But hiding things doesn't improve interoperability.
20:56:01 [Ian]: ack Ian
20:56:01 [Zakim]: Ian, you wanted to pursue bank interaction with lady.
20:57:12 [Ian]: IJ: Would it be possible to terminate transactions when misconfiguration occurs?
20:57:34 [Ian]: SM: Yes, that is a fallback scenario.
20:57:37 [Ian]: IJ: Send back diagnostics.
20:57:52 [Ian]: CL: Like an ATM - it just shuts down and says "Try another"
20:58:06 [Ian]: SM: Almost all voice platforms would log the recasting as a warning.
20:58:25 [Ian]: CL: Does the spec say anything about logging?
20:58:33 [Ian]: SM: Add that there's an expectation that system log it.
20:59:07 [Chris]: expectation of logging clarifies the seriousness of the issue
20:59:26 [Chris]: different expectation of timeliness to fix, in a corporate environment
20:59:50 [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, prompte the user for how to proceed, or, in another (e.g., voice-only) setting, might terminate and log the transaction mishap.
21:00:44 [Ian]: SM: Would it be permissable to continue without user permission, but logging?
21:01:01 [Ian]: JC: The user and voice browser are separated by more distance; user not interacting with the browser.
21:01:16 [Ian]: JC: The issue of how you accept the message is in the domain of the browser maintainer.
21:01:48 [Ian]: JC: "Browser must be configurable to either proceed or return error."
21:02:37 [Ian]: IJ: How does grammar processor talk to browser?
21:02:42 [Ian]: SM: Can happen in different ways.
21:03:11 [Stuart]: zakim, who is here
21:03:11 [Zakim]: Stuart, you need to end that query with '?'
21:03:14 [Stuart]: zakim, who is here?
21:03:14 [Zakim]: On the phone I see Ian, Stuart, Chris, Scott_McGlashan, DanB, ??P8, Jerry_Carter, MaxF
21:03:16 [Zakim]: On IRC I see Brad, maxf, DanB, Chris, DanC, Ian, RRSAgent, Zakim, Stuart
21:03:22 [Ian]: IJ: Two pieces: (1) grammar processor must signal error (2) browser needs to get user permission.
21:03:28 [Ian]: JC: But that interrupts call flow.
21:04:19 [Ian]: SM: I think that logging would be acceptable to Voice WG.
21:04:52 [Ian]: SM: I think the Voice WG would accept a req to inform provider of mismatch, even if agent allowed to proceed.
21:05:55 [Ian]: ADJOURNED
21:06:11 [Ian]: IJ: Next step?
21:06:25 [Ian]: SM: We'll discuss tomorrow at mtg. Depending on the meeting, we can have another discussion.
21:07:21 [Ian]: SW: Perhaps at next meeting, poll TAG for individuals and when they would meet.
21:08:17 [Zakim]: -Scott_McGlashan
21:08:18 [Zakim]: -Stuart
21:08:19 [Zakim]: -??P8
21:08:20 [Zakim]: -DanB
21:08:21 [Zakim]: -Jerry_Carter
21:08:22 [Ian]: RRSAgent, stop