Considering minutes for approval as listed in the agenda.
RESOLUTION: Minutes of 1 Nov, 5 Nov, 6th Nov, and 9 Nov are approved
SW: Any reflections on TPAC week? I thought it was good, and that the TAG made useful progress.
HT: I thought the opportunity for unscripted conversations was even more valuable than usual.
TBL: Me too. We made good connections with other WGs. Stuart and I made good connections with POWDER. A great week. Energy did flag a bit at the end. I liked the balconies etc. at the hotel as meeting places.
HT: We still aren't getting the right balance in domain reports to get people to the microphones. I think we still spent too much time talking from the podium. The AC didn't get the opportunity they needed to talk.
NW: 22 Nov is US Thanksgiving
SW: Let's cancel the 22nd.
TBL: Regrets for the 29th.
NM: Probably regrets for the 29th from me too. At the NSFNet conference in DC.
SW: Henry, can you scribe the 29th?
HT: Yes.
SW: Appreciated, thank you.
<dorchard> is 22nd cancelled?
RESOLUTION: The telcon of the 22nd of November is cancelled.
SW: I've sent out a survey. Some comments from folks like Noah.
NM: For internal IBM reasons, I won't know what I can commit to as far as Europe travel until around Jan. 25.
NW: I have the opposite need, which is to commit early. If I can't commit now, it's harder for me to know what else to turn down.
SW: Please give as full a response as you can on the Web form.
DO: Question: I see there are options for near the Beijing meeting. I thought we had agreed Tim not available for that.
SW: I put it on there for completeness. Some people had asked.
DO: I think it's not an option if Tim can't make it.
SW: It's at least a formal way of finding that out.
TBL: What do yes and no mean?
SW: No means, I really don't want the meeting then, won't attend. See top of form for the interpretations.
TBL: Yes but prefer not is not a commitment to attend?
SW: I'm using this as a straw poll. Also, Bristol can be seen as a proxy for UK.
HT: Concern, if anything, was repeating Southampton. No big deal.
NM: Do you want me to reanswer?
SW: Yes, please.
NM: Will try.
SW: Seem to be some teething problems. Let's discuss. Noah raised styling and preview issues, Norm raised syndication issues.
HT: Would like to have Dan present. Want to know whether he could do separate installation for us. I could do some, but Dan is probably better placed to do it?
SW: Defer for later in this meeting, hoping Dan will join.
ACTION-70 on Stuart Williams to Send a comment to xhtml folks of Please explain your intentions wrt to the use of CURIEs in conjunction with html@href -
SW: See response at http://lists.w3.org/Archives/Public/www-html-editor/2007OctDec/0023 . I thought that was quite positive.
HT: I read it as equivocal. I read it as saying, we have the [...] syntax we can use where people think there's a problem, but we're giving on other guarantees.
SW: I noticed the claim that these are mostly used in new contexts.
HT: It says currently. The spec doesn't warn about using in other contexts.
SW: Should we say: make that clearer, and specifically discourage use in places that have historically carried only URIs. Is that a reasonable response?
HT: I'd like something stronger. Make clearer that in no cases should CURIEs be used where a URI is expected except if [...] syntax is used. In fact, I don't really like the [...] syntax. Indeed, I think it overlaps with RFC 3986 syntax. I think a naked host is a valid URI, and IPV6 has [...].
TBL: I think you need // with the host.
HT: Hmm. Thinking of mailto:. No, that's not it. Anyway, I'd like the going in position to be "CURIEs MUST NOT be used, even with the [...] syntax, in places where current specifications call for only URIs."
DO: Agree
NW: Agree
<Stuart> +1
TBL: I don't much like the [...]. Seems sort of kludgey. I would be happier if, for example, the XML syntax itself were changed, say to get rid of quotes on attributes, to signal use of these. I don't like the microsyntax of this. This is increasing the number of types of attributes there are. Not clear you want to grab [...]. For example, N3 uses it for other things.
<scribe> ACTION: Stuart Williams to respond to Shane on behalf of TAG indicating concerns about [...] syntax and use of CURIEs where URI is expected.
<trackbot-ng> Created ACTION-77 - Williams to respond to Shane on behalf of TAG indicating concerns about [...] syntax and use of CURIEs where URI is expected. [on Stuart Williams - due 2007-11-22].
HT: Checked 3986. Guess I was wrong.
SW: We discussed at the F2F. Henry was going to do some liaison with the staff contact. Seems you had quite a bit of interaction with the group through the week.
HT: I think a lot of good progress was made during the week. I think John Schneider's presentation was well received. I had a chance for good contact with the chair, whom I had not met before. A lot of good level setting happened. People have much more consistent states of knowledge. People don't yet agree, but consensus may be closer. I think the WG has become more aware of what they need to do communication-wise to have effective interaction with the community. I think if it would be good if the TAG reiterated its request that the EXI workgroup further clarify their reasoning as to why doing EXI as a Recommendation is on balance the right thing for the community. They also need to do a better job of highlighting the key use cases.
<Zakim> Noah, you wanted to talk about positioning
<scribe> scribenick: ht
NM: We did decide in our TAG discussions that there's another dimension. If this is eventually made a REC, it's crucial how you position it. No doubt if we didn't go ahead, there would be a bunch of local, non-interoperable 'binary' XMLs, which would be bad for our members, and doing it RF would be good for our members. But if we _do_ go ahead, it's important to try to forestall the expectation that any XML processor should be able to process binary XML. The expectation should be that general-purpose XML implemenations accept teh traditional text forms. We should re-iterate that to the workgroup.
SW: So it shouldn't be called XML, right?
NM: That's an obvious strategy to achieve the goal of reduced expectations, but there might be others
SW: Coord with comm team?
NM: Eventually, but getting agreement between the various interested parties comes first. Particularly what the core use cases are. We need the kind of broad agreement that we had at the onset of XML about what the expected coverage is.
<Noah> SW: Have we looked at their charter?
SW: What about their charter? Seems to me they are chartered to produce a format
<scribe> scribenick: Noah
SW: It demands a format, but otherwise measures of success aren't clear?
HT: We can aske them, as part of communication with W3C and rest of the world.
From charter:
The Efficient XML Interchange Working Group is chartered to define an alternative encoding of the XML Information Set that addresses at least the minimum requirements identified by the XML Binary Characterization Working Group.
NM: I thought those in turn were somewhat too vague, and I thought if anything it committed them to meeting so many use cases that I don't think how they could prove it with realistic detailed test cases representative of each.
<Stuart> http://www.w3.org/2005/09/exi-charter-final.html
DO: I pointed out in my message they talk about meeting certain thresholds, but the characterization document seems not to have thresholds.
NM: I still think we should support them if they pick a few use cases, prove they're of great importance, and show they meet them. I don't think they've helped their case by claiming to meet a very large number of use cases as their measure of success.
DO: The AC Reps who had a position similar to the TAG's may have had a tough time voting properly. To some degree, you do need to do the technical work to find out what's possible. Of course, the AC gets one more opportunity to rule on this, but it's indeed very late in the process.
SW: Awhile ago, Dave drafted a response, which was along the lines of "You have not yet addressed our concerns. F2F seemed to land at mostly harmless". Do we have something all TAG members are comfortable with?
<Zakim> Noah, you wanted to say not mostly harmless
NM: Not mostly harmless if users expect generic XML tools to read it. As long as there's risk of that, it's potentially tremendously harmful. If it's positioned for use where one-off binary formats would have been developed anyway, then probably at worst harmless, and maybe very helpful in providing a royalty-free, interoperable format for those cases.
DO: I don't think we should weaken our stance. We should write down our concerns, and when they're addressed, things will indeed be OK.
HT: Completely agree. Just want to frame our response as "here's what we think you need to do", as opposed to "you made a mistake". The substance may be the same, but the tone is important.
TBL: Yes, we need to show that we understand where they're coming from.
HT: I'm prepared to try to frame it.
SW: OK with everyone?
DO: Yes.
HT: We'll start with an internal draft first, ok, then post publicly once we're in the ballpark among ourselves.
NM: Yes, in general being in public is good, but there are sensitivities here. I think making sure we're speaking carefully here is worth a quick round of internal tuneup to make sure we're saying what we mean before circulating for public review. Shouldn't be a long delay anyway.
<Stuart> trackbot-ng, status
<scribe> ACTION: HT to repackage proposed response to EXI workgroup.
<trackbot-ng> Created ACTION-78 - Repackage proposed response to EXI workgroup. [on Henry S. Thompson - due 2007-11-22].
SW: All done with Binary XML?
SW: Dave, you've make a posting on www-tag. Do you want feedback from the security folks?
DO: Prefer we first make sure the TAG thinks I've got it right.
HT: Haven't read it yet
<Stuart> http://www.w3.org/2001/tag/doc/passwordsInTheClear-52
<dorchard> "Because many systems store passwords a salted hash, it is not possible in practice for both parties using such systems to compute the same initial secret value."
Looking at: http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20071112.html
<dorchard> However, there's no obvious method by which a web browser can reliably know when the data entered is sensitive. Furthermore, in browsers which enable scripting, it may be impossible to know whether the information is transmitted in clear text. For example, many forms use onSubmit actions to start javascript programs. These programs secure the password and then transmit the password and other information. A User Agent cannot examine the javascript to ensure
<Stuart> http://lists.w3.org/Archives/Public/www-tag/2007Nov/0017
Announcement of new draft is at: http://lists.w3.org/Archives/Public/www-tag/2007Nov/0017
SW: 5 minute break while we read it
<Noah_> typo to fix: "Because many systems store passwords a salted" -> "Because many systems store passwords AS a salted"
<timbl_> Try not to go meta -- "The Tag is of te opinion that" ...
<timbl_> similarly, "we could use another 'Good Practice'
<timbl_> try to phrase it from he point of view oft reader
<Stuart> I think we could do with a paragraph break ahead of: "Because users often cannot tell when a password..."
<Norm> s/stop the crawling of the pages/stop web crawlers/
<timbl_> s/is being send in the clear or not/is being sent in the clear or not/
<Norm> Suggest "stop the crawling of the pages" -> "stop web crawlers"
<Noah_> Is it intentional that there's no explicit mention of WS Security in the SOAP-related section?
<Stuart> Also... we seem to say it's ok to use the 'weak padlock' - I am a little confused about the advice we're giving.
<Norm> "is being send" -> "is being sent"
<Noah_> First item in the biblio is missing a [XXXX] key.
<timbl_> Should we not mention client-side certs?
<Noah_> I think a grammar pass is needed.
HT: I think too much time is spent saying what we're not saying.
<Stuart> I think that the WSC folks argue that the accidential re-use of a password in a more secure context is a serious risk.
HT: I once got good advice from someone years ago: "In standards documents, try not to say what doesn't happen"
SW: Which parts?
HT: Para under 2nd good practice says why there isn't a 3rd. If you hadn't been in our debate, you wouldn't understand this.
TBL: I don't like to do say "The TAG thinks XXXX"
... Giving maps that help you to avoid ratholes is useful. That's why we explain the limits of digest.
DO: I think warning of the rathole is useful.
HT: OK. I guess it needs its own paragraph.
... A little more background would help.
... Don't say "WE thought about XX", rather "XXX is not in general possible for the following reasons"
<Stuart> wrt the "weak padlock" should add "Administrators using a clear text password to, for example avoid scanning by search engines, need to be aware that passwords used for this kind of purpose SHOULD NOT re-use the same password in contexts that are more sensitive."
NM: I think it's mainly trying to say the right things, but would benefit from careful wordsmithing, and grammar checks. Also, there are major sections like 2 that have useful information, but no punchline. Are you supposed to use digest, or are we just noting that it's there?
SW: wrt the "weak padlock" should add "Administrators using a clear text password to, for example avoid scanning by search engines, need to be aware that passwords used for this kind of purpose SHOULD NOT re-use the same password in contexts that are more sensitive."
<timbl_> Addessing HT's comments on the pre-2.1 paragraph:
HT: I'm confused be reference to administrator.
<timbl_> Automatic Protection by User agent
<timbl_> It is tempting to build user agents which refuse to snd sensitive data in the clear, or to warn users.
<timbl_> There are two problems.
<timbl_> Firstly, the user agent cannot determine what is sensitive. It is not always input using password masking, often for good reason.
<timbl_> Secondly, when javscript is enabled, the script can use te password in the clear in many ways, which are too hard for the browser to analyse.
<timbl_> __________________________
HT: John Cowan's examples are typically ....
SW: I'm not wedded to "administrator", but imagine trying to find a printer, then I'm imagining that some administrator is going to set that printer up with a password. That's different than me having an account.
HT: Are we straddling two examples?
SW: The spirit is "whoever is setting up the password should be aware of the risks they're taking".
HT: What you said but didn't write is that the person is both choosing and distributing the password. Didn't realize we were on that use case. Usually people choose their own passwords. I think that's more common.
NM: Does it matter whether administrator chooses one per user or not?
TBL: Looking at the para preceeding 2.1. See proposal in IRC log above.
HT: I think that's useful.
TBL: Are you happy with that text?
DO: New section of 2.1?
TBL: No.
HT: Maybe a header in front of a colon.
TBL: Maybe an H4.
<Noah_> Editorial suggestion: "tempting to build user agents which" -> "tempting to build user agents THAT" I think it's restrictive, right?
SW: Dave, do you have what you need?
DO: Yes.
<timbl_> Because users often cannot tell when a password is being send in the clear or not, we could use another 'Good P...javascript to ensure that the password is not transmitted in clear text. Because of these limitations, this finding provides no Good Practice advice to User Agent authors.
<Noah_> Looks like we're not going to get to the blog question today. Given that I'm likely gone the next 2 weeks, I'd welcome some email feedback on whether I'm off base in pushing hard for a blog that allows robust preview and flexible use of both HTML TAGs and CSS?
DO: Aiming to get it done today or tomorrow.
HT: I've circulated a new draft of namespaceDocument-8
SW: Brilliant. Will be on agenda for next time.
<Stuart> http://www.w3.org/blog/tag
<Stuart> http://www.w3.org/blog
<Stuart> http://www.w3.org/blog/systeam
<Stuart> TAG folk please go complete: http://www.w3.org/2002/09/wbs/34270/2008-F2F-Schedule/