16:05:10 <RRSAgent> RRSAgent has joined #tagmem
16:05:10 <RRSAgent> logging to http://www.w3.org/2006/10/04-tagmem-irc
16:05:46 <DanC_lap> agenda + Convene, take roll, review agenda
16:05:51 <Zakim> Zakim has joined #tagmem
16:05:53 <DanC_lap> agenda + Convene, take roll, review agenda
16:05:57 <ht> ht has joined #tagmem
16:06:03 <DanC_lap> Making our calls more efficient
16:06:10 <DanC_lap> agenda + Making our calls more efficient
16:06:31 <Noah> Noah has joined #tagmem
16:06:33 <ht_vancouver> scribe: ht
16:06:40 <ht_vancouver> scribe: Henry S Thompson
16:06:46 <ht_vancouver> scribenick: ht
16:08:32 <ht_vancouver> zakim, take up agenda 1
16:08:32 <Zakim> agendum 1. "Convene, take roll, review agenda" taken up [from DanC_lap]
16:09:30 <ht_vancouver> Scribe duty: HST Wed a.m.; DC Wed p.m.; NDW Thu a.m.; NM Thu p.m.
16:09:49 <ht_vancouver> Minutes from last telcon approved
16:10:05 <timbl> timbl has joined #tagmem
16:10:22 <ht_vancouver> Next telcon 10 October
16:10:36 <ht_vancouver> TV Raman regrets for 17 October
16:10:51 <ht_vancouver> D Orchard probable regrets 17 October
16:12:07 <ht_vancouver> VQ: Add to agenda, Nov AC Meeting report and discussion
16:12:45 <ht_vancouver> ... We will come to this later in the meeting
16:13:02 <ht_vancouver> ... HST, TBL, VQ and NM will be there, others not
16:13:33 <ht_vancouver> VQ: Next f2f December 11--13 in Boston
16:13:55 <ht_vancouver> NDW: Pbly not available all three days. . . 
16:15:37 <ht_vancouver> TBL: There's a Web Services Transfer submission which is relevant. . .
16:16:02 <ht_vancouver> ... Could we have a short slot in the agenda to at least raise an issue
16:16:05 <ht_vancouver> VQ: Will do
16:16:22 <ht_vancouver> Zakim, next agendum
16:16:22 <Zakim> agendum 2. "Making our calls more efficient" taken up [from DanC_lap]
16:16:31 <DanC_lap> (booted the meeting and did admin in 16 minutes flat. well done, VQ)
16:17:57 <ht_vancouver> VQ: TV asked for a discussion about this -- DC has sent email on this, let's read that and discuss in breaks etc., but not spend official f2f time
16:18:05 <Vincent> Vincent has joined #tagmem
16:18:20 <DanC_lap> (on meeting efficiency http://lists.w3.org/Archives/Member/tag/2006Oct/0011.html )
16:18:21 <ht_vancouver> topic: metadataInURI-31
16:18:38 <ht_vancouver> VQ: We've approved publication, but there have been recent comments
16:19:23 <ht_vancouver> NM: We decided in June to publish subject to ER review.  He said "Go ahead", but raised an issue wrt file extensions, DC agreed
16:19:32 <Noah> New draft of metadata in URI: http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061001.html
16:19:44 <Noah> New section is main change: http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061001.html#malicious
16:20:07 <ht_vancouver> ... Added new section, URI above, plus small changes per input from Stuart
16:20:31 <ht_vancouver> ... There's been some feedback, both pos. and neg
16:20:40 <DanC_lap> (+1 license to fix that email address without discussion)
16:20:51 <ht_vancouver> ... ER is now happy, there are some editorial fixes I'll do w/o discussion
16:21:44 <ht_vancouver> ... The most substantive issue is whether we have the new section at all -- Mark Baker says the old version said the truth, now we've got this extra bit
16:21:44 <timbl> q+
16:21:52 <DanC_lap> q+ to suggest switching to saving foo.jpeg
16:22:44 <ht_vancouver> TBL: This is not the story I would have picked, it's backwards from the classic pblm case
16:23:21 <DanC_lap> (tbl makes my point exactly. it's the mangling of metadata when you save it that is the classic case.)
16:23:29 <Vincent> ack timbl
16:24:29 <Vincent> ack DanC
16:24:29 <Zakim> DanC_lap, you wanted to suggest switching to saving foo.jpeg
16:24:32 <ht_vancouver> ... Content-Disposition: foo.jpg.exe, so even if image/jpg and URI is foo.jpg, the saved file has lost its mime type
16:24:48 <Norm> q+
16:24:53 <ht_vancouver> Or, simpler, there's an image, user saves it w/o ever noticing its URI, which was .exe
16:27:07 <ht_vancouver> TV, DC: Don't think the Content-Disposition thing actually happens
16:29:16 <ht_vancouver> NM: ER raised this, I need to be sure this is the right example
16:29:46 <Norm> ack Noah 
16:29:48 <Norm> ack norm
16:31:07 <Vincent> ack Norm
16:31:07 <ht_vancouver> TBL: I think Ian Hixon has mime-type tests which explore this
16:31:26 <DanC_lap> (security considerations of MIME is a whole RFC http://www.faqs.org/rfcs/rfc2046.html )
16:31:56 <ht_vancouver> NDW: I think you've covered ER's case, not necessarily even .exe, just a disconnect between filename and media type
16:33:07 <ht_vancouver> ... Consider just bigstar.foo, served as image/jpg, works in browser, but if saved to disk, won't work anymore.
16:33:20 <ht_vancouver> DC: But it's the security case that really needs to be told
16:34:01 <ht_vancouver> NM: So you want the 'saved as exe' case
16:34:04 <ht_vancouver> DC: Yes
16:34:14 <EdR> EdR has joined #tagmem
16:36:31 <ht_vancouver> NM: What I'm hearing most is rewrite this the other way around
16:36:32 <ht_vancouver> ... that is, served as image/jpg, saved as .exe
16:38:42 <dorchard> dorchard has joined #tagmem
16:39:46 <ht_vancouver> VQ: Three options: remove, keep, rewrite
16:40:03 <ht_vancouver> HST: I have a slight preference to _adding_ the new story
16:41:14 <ht_vancouver> NM: I'm a bit concerned that the bug in the new story is the mime type, so it's not a metadata-in-uri issue at all
16:42:04 <dorchard> Ed, you should say that on the record rather than in /me
16:42:06 <DanC_lap> q+ to note our obligation to write up this exe/jpeg security issue was present in the authoritative metadata finding too, and to see what we did in that case
16:42:29 <ht_vancouver> TVR: TBL summarised it well: At the browser level, you're trusting the mime type, but once saved, the OS is trusing the metadata, and the conflict can get you in trouble
16:42:38 <EdR> ok, for the record.. I'd rather keep the section because I think its an important addition.
16:42:50 <Vincent> ack DanC
16:42:50 <Zakim> DanC_lap, you wanted to note our obligation to write up this exe/jpeg security issue was present in the authoritative metadata finding too, and to see what we did in that case
16:42:54 <ht_vancouver> DC: I think we already wrote this up -- see section 4.4 of Authoritative Metadata
16:43:38 <Noah> See also:
16:43:41 <Noah> http://www.w3.org/2001/tag/doc/mime-respect-20060412#consent
16:44:17 <ht_vancouver> HST: So we could leave the section as it is, and add a cross-reference to the AM 4.4 story
16:44:57 <ht_vancouver> NM: But MB has trouble with the example as written
16:45:10 <timbl> http://ln.hixie.ch/?start=1154950069&count=1   "However, it seems that these real world concerns are not a factor in the TAG's findings, since the day after I posted the aforementioned blog post, they published a document describing how browsers must always follow Content-Type headers, how specifications must never require browsers to ignore such headers, and how authors must all go and correct their mis-configured servers. (I only recently became aware of this d
16:45:20 <ht_vancouver> DC: Just octet-stream doesn't get it run
16:45:30 <ht_vancouver> ... that depends on the extentsion
16:45:39 <ht_vancouver> s/extentsion/extension/
16:46:45 <timbl> See http://www.hixie.ch/tests/adhoc/http/content-type/
16:48:29 <timbl> I am happy hat Safari donloads   http://www.hixie.ch/tests/adhoc/http/content-type/007.dmg.gz which has    as  007/dmg.gz.txt 
16:48:40 <timbl> as it has content type text/plain
16:49:19 <EdR> Tim, link 1 in your test page http://www.hixie.ch/tests/adhoc/http/content-type/001.txt runs in IE.  Good example.
16:53:19 <EdR> this is what I see..
16:53:20 <EdR> This is NOT a text file. You should have been told it was an application/x-hixie-test file. If you were offered this file as if it was a text file, or if you were told the MIME type was text/plain, then this test has FAILED. 
16:53:54 <timbl> q+
16:56:45 <ht_vancouver> [The group experiments with several of the Hixie tests and various browsers, but w/o hitting any security issues]
16:56:56 <timbl> q-
16:57:45 <ht_vancouver> NM: So it looks like what I wrote is just wrong -- application/octet-stream is not sufficient to cause a browser to try to run anything
16:58:28 <ht_vancouver> ... So what I think I should do is xref AM
17:00:01 <EdR> The issue in my mind is can the user trust what he sees in his email/web page.  If he sees .png is a a .png file or something else.
17:00:04 <ht_vancouver> TBL: Conclusion is that the browsers should stick to WebArch, and that we should give a thumbs-up to saving with filenames consistent with actual metadata, i.e. mime type, as safari does
17:02:44 <DanC_lap> +1 s/identity/URI/g
17:02:51 <ht_vancouver> TBL, HST: The word 'identity' is used for what is just its name
17:03:31 <ht_vancouver> ... this should be fixed where it needs to be
17:04:27 <ht_vancouver> NM: So this all nets out -- remove current new chapter, add new chapter about a) misleading users, b) encourages preserving definitive media type information in OS-specific ways
17:05:07 <DanC_lap> (indeed, I concur with the advice as NM played it back.)
17:05:52 <ht_vancouver> NM: Also xref AM 4.4
17:06:54 <Noah> See GPN http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061001.html#guessing
17:07:46 <ht_vancouver> NM: I'd like to kill this, the text above it tells the full story OK
17:08:21 <ht_vancouver> DO: I sort of like this
17:08:45 <ht_vancouver> NM: It's tautological -- it says don't do risky things unless you are prepared to take the risk
17:10:23 <DanC_lap> q+ to suggest: constraint: Parties that guess information from the URI beyond standards and stated policies accept the risks for any resulting failures.
17:10:35 <ht_vancouver> HST: No it's not, it conveys the risk which may not otherwise have been understood
17:10:39 <Vincent> ack danc
17:10:39 <Zakim> DanC_lap, you wanted to suggest: constraint: Parties that guess information from the URI beyond standards and stated policies accept the risks for any resulting failures.
17:11:55 <Noah> Suggest Dan's text as GPN.
17:12:53 <ht_vancouver> [General argument about whether DC's text can be a constraint -- we can't tell people what they must take responsiblity for]
17:13:16 <ht_vancouver> TBL: I think there are problems going in that direction
17:13:30 <ht_vancouver> DO: I find it readable and helpful
17:13:38 <ht_vancouver> NM: I'm inclined to drop it
17:14:01 <ht_vancouver> DC: I can't live with keeping it
17:14:02 <DanC_lap> [we can tell people what they are responsible for.]
17:15:42 <ht_vancouver> HST: "Don't get cheesed of if guessing doesn't work"
17:15:53 <ht_vancouver> DC: That's not a Good Practice
17:16:02 <ht_vancouver> HST: True -- it's not a Constraint either
17:16:16 <ht_vancouver> DO, HST: Can live without it
17:16:35 <ht_vancouver> DO: But I'm sorry to lose a GPN here altogether
17:17:14 <Noah> Guessing information from URIs can be a valuable way of exploring the Web, but it brings the risk that ....
17:17:25 <ht_vancouver> Resolved: Remove the GPN at the end of section 2.2 in its in current form
17:18:10 <ht_vancouver> NM: Pull back from claiming this is out the door, but we should focus feedback on changes, not untouched stuff
17:18:20 <ht_vancouver> ... Will try to have a new draft in two weeks
17:19:24 <DanC_lap> Ed and DanC to review it
17:19:44 <DanC_lap> so Noah, if you get it out on Weds or Thu before a Tuesday telcon, that's optimal for me.
17:19:44 <ht_vancouver> VQ: End of this topic, short break
17:38:58 <ht_vancouver> topic: GenericResouces-53
17:39:17 <ht_vancouver> http://www.w3.org/2001/tag/doc/alternatives-discovery.html
17:39:44 <DanC_lap> +1 ship it http://www.w3.org/2001/tag/doc/alternatives-discovery.html Oct 2, 2006 11:24:06 AM
17:39:46 <ht_vancouver> VQ: We agreed that once the figure was added, we could publish, and the figure has been added
17:40:51 <ht_vancouver> ... Are we ready to go?
17:41:49 <ht_vancouver> TVR: Stuart raised some questions wrt representation vs. resource -- I think it's OK as is. . .
17:43:13 <ht_vancouver> q+ to raise a few points
17:44:00 <ht_vancouver> VQ: Not sure about the dotted lines -- they appear to connect only the corners, but they're supposed to start at the middle and go out
17:44:25 <ht_vancouver> TVR: No, they are there to show that links don't have to go through the generic
17:44:32 <Vincent> ack ht
17:44:32 <Zakim> ht_vancouver, you wanted to raise a few points
17:44:37 <ht_vancouver> 2.1.1 -- Make sure "http://example.com/ubiquity/resource" is identified as the "canonical URI".
17:45:16 <ht_vancouver> 3 -- "Contrast these findings with the metadata in URIs and state
17:45:16 <ht_vancouver> finding which each enumerate use cases where it is advisable not to
17:45:16 <ht_vancouver> encapsulate user context in URIs."  I find this opaque at best, not
17:45:16 <ht_vancouver> well-prepared, no actual references. . .
17:45:16 <DanC_lap> TV: ok, I'll change canonical URI to generic resource there. good point, HT
17:46:55 <ht_vancouver> TVR: This was added after the June meeting, to deal with TBL's example of bank accounts
17:46:57 <timbl> q+
17:47:14 <ht_vancouver> ... I'll improve that
17:47:19 <ht_vancouver> ... and add real references
17:47:22 <DanC_lap> (hmm.. this is the 2nd case of overlap between findings today... makes me think we're starting to turn the corner between where separate findings are more efficient and where a composite volume is better.)
17:47:41 <ht_vancouver> ack timbl
17:48:35 <ht_vancouver> TBL: Abstract -- add representations using different content type and different versions
17:49:54 <ht_vancouver> ... Intro -- 3 goals, what happened to ensuring the specific resources are not individually indexed?
17:51:13 <ht_vancouver> HST: That means there needs to be a way to get reliably from the specific to the generic, _knowing_ it's generic
17:51:57 <ht_vancouver> TBL: So you need to have the metadata
17:52:20 <ht_vancouver> HST: Including the specific info that _this_ link is the one to follow to get to the generic resource
17:52:42 <ht_vancouver> TVR: So, should we recommend role='generic', or some such?
17:53:20 <ht_vancouver> TBL: Yes, but that's weak -- I'm worried we'll end up with a mixture of different ways of doing things
17:53:57 <ht_vancouver> TVR: How do we go about owning role='generic'?
17:54:02 <DanC_lap> (timbl's ontology http://www.w3.org/DesignIssues/Generic )
17:54:22 <ht_vancouver> DC: Use appropriate GRDDL pointer at the top
17:54:34 <ht_vancouver> ... StandardFieldValues-51
17:54:59 <ht_vancouver> ... Use, and say see also SFV-51
17:56:17 <ht_vancouver> TBL: I should be able to bookmark the japanese version
17:56:24 <ht_vancouver> HST: Sure, but Google shouldn't index it
17:56:56 <DanC_lap> (timbl's ontology suffers from http://esw.w3.org/topic/HasPropertyOf . I think timbl would agree it should use http://esw.w3.org/topic/RoleNoun )
17:57:11 <ht_vancouver> TVR: There's a bug wrt pagerank here
17:57:38 <ht_vancouver> TBL: So clearly the metadata would help, but it needs to be consistently interpretable. . .
17:58:50 <ht_vancouver> TVR: So do I write rel='generic' or not?
17:58:57 <DanC_lap> DC suggests that anything about rel="generic" should note issue http://www.w3.org/2001/tag/issues.html#standardizedFieldValues-51 in the same breath.
17:59:05 <timbl> http://www.w3.org/DesignIssues/Generic.html has an ontology
18:00:26 <ht_vancouver> HST: We could just be brutally frank, and say that to solve the pagerank pblm, more work needs to be done, perhaps folk could try rel='generic' and if it works, standardise it
18:00:40 <ht_vancouver> ... rel='nofollow' is a precedent
18:00:58 <ht_vancouver> DC: Not a great precedent, didn't go through channels
18:01:03 <DanC_lap> +1 the tom sawyer approach... sketch rel="generic", note issue 51, note "more work needs to be done, and a TAG finding isn't really the place. If you want to work on it, sign up here ___ ."
18:01:46 <Vincent> ack danc
18:02:21 <ht_vancouver> TBL: not just rel='generic', but rel='lang-specific' and . . .
18:02:27 <DanC_lap> in timbl's ontology http://www.w3.org/DesignIssues/Generic , the terms are u:isLanguageSpecficVersionOf etc.
18:02:45 <ht_vancouver> ... I produced an ontology with relations and classes
18:04:17 <ht_vancouver> DC: I mean there should be an explicit reference to TBL's paper, URL above
18:05:03 <dorchard> dorchard has joined #tagmem
18:05:47 <DanC_lap> [re 3-place predicates, timbl has written that up too. http://www.w3.org/DesignIssues/InterpretationProperties ]
18:06:25 <ht_vancouver> DC: We could point to it as is, or we could actually send TBL and DC off to work on this
18:06:55 <ht_vancouver> TVR: I think we do people a disservice if we point to something we're not working on
18:07:49 <ht_vancouver> HST: I'd prefer the opposite, that is, "Here's an example of the kind of thing we mean", more work still needed
18:08:43 <ht_vancouver> DC: By "sign up here" I did mean something as explicit as a WBS form. . .
18:09:40 <tvraman> tvraman has joined #tagmem
18:10:12 <DanC_lap> HT: I think yes, there should be a 4th point about search.
18:10:16 <DanC_lap> TV: yes, OK.
18:10:21 <ht_vancouver> HST: So I think you should add a goal, and add a section to address it
18:10:51 <ht_vancouver> TBL: Example URI changes from /newspaper to /ubiquity -- should be consistent
18:11:20 <ht_vancouver> ... Also, needs to end with / so conneg will work
18:11:35 <ht_vancouver> ... and explain why it needs to be there
18:12:49 <ht_vancouver> ... which is, so that the base URI for foo/index.html is foo/
18:13:16 <DanC_lap> 302 Found  ... 10.3.3 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3
18:13:19 <ht_vancouver> TBL: Is gloss for 302 correct -- should be 302 found
18:13:43 <ht_vancouver> ... Why encourage redirection over conneg?
18:14:23 <ht_vancouver> TVR: I originally only wanted to do one of these -- added the other as a result of www-tag feedback
18:14:45 <ht_vancouver> TBL: They're not equivalent -- redirection is more expensive
18:15:18 <ht_vancouver> TVR: So "redirection requires an extra roundtrip, and may have significant impact for mobile devices"
18:15:35 <DanC_lap> (I'm happy that timbl can read this sort of thing with fresh eyes. I can only see what I already know, most of the time.)
18:17:23 <ht_vancouver> TBL: frozen in, in 2.1.1 bullet 4
18:17:39 <ht_vancouver> ... Not bookmarked, just base URI, right?
18:17:52 <ht_vancouver> TVR: So I agree this text is a bit misleading
18:18:45 <ht_vancouver> TBL: The impact on resolving relative URIs certainly could be discussed
18:18:58 <Noah> Noah has joined #tagmem
18:20:38 <ht_vancouver> ... Once the specific content has been returned, the links within it may be fully-explicit, to save repeated redirects.
18:23:25 <ht_vancouver> TBL: Channeling Stuart Williams, suggest replacing most/all uses of 'representation' with 'specific resource'
18:24:49 <DanC_lap> (I'm content with the fact that a representation, like everything else, is a resource, so it doesn't do too much harm to discuss URIs for representations.)
18:26:03 <DanC_lap> (though I'm happy that HT seems to be persuading TV that "specific resource" is better.)
18:26:39 <ht_vancouver> HST, TBL, NM: To and fro wrt whether multiple URIs imply multiple resources
18:26:58 <ht_vancouver> TVR: I guess I like the change, because it makes the contrast with generic resource better
18:27:33 <ht_vancouver> TBL: The other reason is that it's media type variation which goes with different representations
18:29:02 <ht_vancouver> NM: So do we add a separate story for media type?
18:29:04 <DanC_lap> (Noah, we haven't decided *anything* today. The chair hasn't put any questions. You can ask the editor what advice he's most likely to follow, but please don't speak as though we've decided anything.)
18:29:33 <ht_vancouver> TVR: Not sure about how far I'm going with that, no
18:30:30 <ht_vancouver> NM: I'm not clear it's the right message to send that there _should_ be three URIs, one generic, one for jpg and one for gif ?
18:30:47 <ht_vancouver> ... Can't really be the same, since there's no metadata in them, so they can't crosslink
18:31:07 <ht_vancouver> TBL: The header can link back
18:31:08 <timbl> Link: rel=generic
18:31:13 <timbl> Link: rel=meta
18:31:26 <Norm> timbl, those are HTML headers, no?
18:32:01 <timbl> fbow?
18:32:10 <Norm> for better or worse
18:32:15 <timbl> :)
18:32:16 <timbl> w
18:32:22 <timbl> imho
18:32:24 <timbl> imo
18:33:33 <timbl> ________________________________
18:34:24 <timbl> $ curl -I http://www.w3.org/Icons/w3c_home
18:34:24 <timbl> HTTP/1.1 200 OK
18:34:24 <timbl> Date: Wed, 04 Oct 2006 18:33:03 GMT
18:34:25 <timbl> Server: Apache/1.3.37 (Unix) PHP/4.4.3
18:34:25 <timbl> Content-Location: w3c_home.png
18:34:25 <timbl> Vary: negotiate,accept
18:34:27 <timbl> TCN: choice
18:34:29 <timbl> P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml"
18:34:31 <timbl> Cache-Control: max-age=2592000
18:34:33 <timbl> Expires: Fri, 03 Nov 2006 18:33:03 GMT
18:34:35 <timbl> Last-Modified: Mon, 24 Jul 2006 14:58:33 GMT
18:34:37 <timbl> ETag: "44c4e019;44c5b30b"
18:34:39 <timbl> Accept-Ranges: bytes
18:34:41 <timbl> Content-Length: 1936
18:34:43 <timbl> Content-Type: image/png; qs=0.7
18:34:45 <timbl> ______________________________
18:36:32 <ht_vancouver> DC, NM: Discussion of basic conneg example, around the question of whether the normal case requires at least three retrievable URIs, e.g. one for the undifferentiated image, one for each of png and jpg
18:37:15 <ht_vancouver> TVR: Can't I negotiate for resolution, where synthesis on the fly is much more likely
18:38:41 <ht_vancouver> NM: Back to the finding --- is media type on the same level as natural language, user agent, etc. ?
18:39:09 <ht_vancouver> ... Extending the Good Practice to that axis is not straightforward
18:39:28 <ht_vancouver> ... In particular because there is no place for metadata
18:39:43 <ht_vancouver> DC: That's why it's a 'should', not a 'must'
18:40:14 <ht_vancouver> DC: But yes, I think that's the advice, that's the best outcome
18:41:10 <ht_vancouver> TBL: Yes, best if we could include Link rel='generic' in the response, plus more info about the overall graph of relations
18:41:50 <ht_vancouver> NM: OK, I didn't understand WebArch to require the separate URIs for the gif and the png
18:42:08 <ht_vancouver> DC: Not 'require', it's a 'should', not a 'must'
18:42:49 <ht_vancouver> TBL: There is a difference, certainly -- language difference is out front, media type is behind the scenes
18:43:11 <ht_vancouver> NDW: Being able to name the individual ones can be v. useful
18:44:31 <ht_vancouver> DC: Can TBL look at TV's next set of edits until convergence?
18:44:40 <ht_vancouver> TV: End of October before I get back to this
18:47:42 <ht_vancouver> NM: I've sent editorial comments by email, for TV's use
18:47:49 <DanC_lap> Zakim, this is tag
18:47:49 <Zakim> sorry, DanC_lap, I do not see a conference named 'tag' in progress or scheduled at this time
18:48:27 <ht_vancouver> VQ: TBL to review, then we'll put it on the agenda
18:49:06 <ht_vancouver> TVR: Update Abstract, add item about search, address the rel='generic' question, deal with the media type issue as just discussed
18:49:54 <ht_vancouver> VQ: Adjourned for lunch, PW in the clear after lunch, then most of the afternoon on Versioning
18:50:20 <ht_vancouver> ... Most of morning tomorrow on that as well
18:52:29 <timbl> adned = adjourned sine die
20:14:08 <tvraman> tvraman has joined #tagmem
20:19:17 <Noah> Noah has joined #tagmem
20:23:17 <DanC_lap> Scribe: Dan Connolly
20:23:21 <DanC_lap> ScribeNick: DanC_lap
20:23:35 <DanC_lap> Topic: Issue passwordsInTheClear-52
20:23:49 <DanC_lap> -> http://www.w3.org/2001/tag/doc/passwordsInTheClear-52 draft 26 Sep
20:24:03 <DanC_lap> ER: so I was aiming for front-side-of-one-page...
20:24:43 <DanC_lap> ... I got some good feedback.. editorial stuff from DanC, SOAP stuff from Paul Cotton, ...
20:25:33 <DanC_lap> ... these edits are in a draft I have sent to VQ...
20:25:45 <DanC_lap> VQ: shall I commit that rev?
20:26:09 <DanC_lap> (edits Ed has made recently are not in v 1.01 2006/09/26 19:23:58 )
20:26:40 <DanC_lap> Ed: so is it way too small?
20:26:48 <Noah> q+
20:26:49 <DanC_lap> HT: size is good.
20:27:14 <DanC_lap> DC: yeah.
20:27:52 <DanC_lap> HT: I sent some editorial stuff... but on the border between editorial and substantive... the yankee group claim seemed a little out of place.
20:28:13 <Vincent> Latest version of Ed's draft: http://www.w3.org/2001/tag/doc/passwordsInTheClear-52.html
20:28:17 <timbl> timbl has joined #tagmem
20:28:23 <timbl_> timbl_ has joined #tagmem
20:28:55 <DanC_lap> HT: on "there are now many authorities for private key"... I think "for certificates" is what we mean...
20:29:16 <timbl> q+
20:30:43 <dorchard> dorchard has joined #tagmem
20:31:17 <Noah> I'd prefer to see, if anything, "A variety of commercial and non-commercial systems are available for administering security credentials such as public key certificates.  References are available on the Web."
20:32:03 <DanC_lap> TBL: re verisign... (a) I don't want to endorse the existing centralized certificate infrastructure, and (b) it's not vendor neutral to mention one vendor without the others
20:33:09 <Norm> q?
20:33:19 <Vincent> noah
20:33:44 <Noah> Current:
20:33:45 <Noah> Therefore its imperative that any corporation who wishes to safeguard its customers data
20:34:02 <Noah> Proposed: Therefore its imperative that any organization that wishes to safeguard its data
20:34:15 <Noah> Proposed: Therefore it's imperative that any organization that wishes to safeguard its data
20:34:17 <DanC_lap> v 1.01 2006/10/04 12:23:58 http://www.w3.org/2001/tag/doc/passwordsInTheClear-52.html
20:34:26 <Vincent> ack noah
20:35:12 <DanC_lap> NM: re "corporations", I think any organization is relevant, not just corportations
20:36:43 <DanC_lap> NM: also, re "A password MUST NOT be transmitted in clear text.", how about "over the public Internet" or something.
20:36:59 <DanC_lap> q+ to ask that we swap in the IETF docs on this
20:37:20 <dorchard> q+ to support not watering down the advice
20:39:10 <Vincent> ack timbl
20:39:10 <DanC_lap> ack timbl
20:39:40 <DanC_lap> TBL: re "The password is available in browsing history." really? how?
20:40:15 <DanC_lap> Ed: if it's visible in a form, and you go back, you'll see it again.
20:40:33 <Noah> Current: The password is available in browsing history. 
20:40:56 <Noah> Proposed: Passwords entered into forms are sometimes retained in the browsing history. 
20:41:44 <DanC_lap> TBL: what does that have to do with passwords over the wire?
20:41:57 <DanC_lap> Ed: ah.. yes... should be moved to the section on password display
20:42:26 <DanC_lap> TBL: the good practice note... who is it aimed at? I suggest server administrators, and browsers.
20:42:46 <DanC_lap> +1
20:43:17 <DanC_lap> TBL: browsers should refuse to send passwords in the clear. so that's 2 good practice notes
20:43:26 <DanC_lap> DO: you don't mean server software designers?
20:43:35 <DanC_lap> TBL: no, I mean the publisher, the site administrator
20:45:11 <DanC_lap> q+ to note "SSL is a protocol developed for trasmitting private documents" is off by a bit.
20:48:26 <DanC_lap> TBL: you can avoid passwords in the clear without using the certificate hierarchy
20:49:31 <DanC_lap> TV: right; contrast SSL with SSH. SSH works without a hierarchy
20:49:33 <DanC_lap> q+
20:49:45 <Vincent> acl DanC
20:49:51 <Vincent> ack DanC
20:49:51 <Zakim> DanC_lap, you wanted to ask that we swap in the IETF docs on this and to note "SSL is a protocol developed for trasmitting private documents" is off by a bit. and to 
20:51:04 <EdR> http://ietfreport.isoc.org/all-ids/draft-iab-auth-mech-05.txt
20:51:44 <DanC_lap> (the IETF doc I remember is older than draft-iab-auth-mech-05 )
20:52:55 <EdR> RFC3552, particularly section 4.1?
20:53:14 <DanC_lap> ftp://ftp.rfc-editor.org/in-notes/rfc3365.txt Strong Security Requirements for Internet Engineering Task Force Standard Protocols
20:53:50 <EdR> http://www.ietf.org/rfc/rfc3552.txt
20:54:28 <Vincent> ack dorchard
20:54:28 <Zakim> dorchard, you wanted to support not watering down the advice
20:54:52 <DanC_lap> TV: the finding should perhaps talk about TSL in addition to or instead of SSL
20:55:36 <DanC_lap> DO: let's not water it down. keep the "MUST NOT do passwords in the clear" as is
20:57:18 <DanC_lap> Ed: so ... in sum... make SSL vendor stuff vendor neutral, [missed], separate "browsers should not...", look into SSL vs TSL...
20:57:50 <DanC_lap> ACTION Ed: revise "passwords in the clear" in light of Vancouver discussion.
20:58:03 <DanC_lap> Ed: I'm interested to turn this around tonight.
20:58:49 <DanC_lap> .
20:58:49 <DanC_lap> .
20:58:53 <DanC_lap> Topic: Issue XMLVersioning-41
20:59:17 <DanC_lap> VQ: new draft 29 Sep...
20:59:35 <DanC_lap> VQ: there's also a new WD from the XML Schema WG on versioning in XML Schema 1.1
21:01:24 <DanC_lap> DO: starting with the schema 1.1. versioning stuff...
21:01:43 <DanC_lap> -> http://www.w3.org/TR/2006/WD-xmlschema-guide2versioning-20060928/ Guide to Versioning XML Languages using XML Schema 1.1
21:02:00 <DanC_lap> DO: so this new WD in the Schema WG covers much of the same ground as part 2 of the TAG finding
21:03:01 <DanC_lap> TV: so the "acid" test... meta excercise... can you express the versioning story from XML Schema 1.0 to XML Schema 1.1 according to this guide?
21:03:21 <DanC_lap> NM: well, some of the changes are not in the markup but in the rules for [what matches what]
21:04:05 <DanC_lap> DO: let's look at the intro... "Weak wildcards - permits wildcards adjacent to optional elements"
21:04:12 <DanC_lap> ... these new mechanisms are worth note.
21:04:31 <DanC_lap> ... "2. Updated All Group - wildcards within All Group" "3. Negative wildcard - exclude specific namespaces and names"
21:05:10 <DanC_lap> q+ to ask about validating XHTML 1.0 documents against XHTML 1.1 schema. are there XML Schemas for XHTML?
21:05:15 <DanC_lap> ack
21:05:38 <Vincent> ack danc
21:05:38 <Zakim> DanC_lap, you wanted to ask about validating XHTML 1.0 documents against XHTML 1.1 schema. are there XML Schemas for XHTML?
21:07:22 <DanC_lap> DanC: does the XHTML 1.1 schema match XHTML 1.0 documents? is it supposed to?
21:07:26 <DanC_lap> HT: I'm not sure.
21:09:50 <DanC_lap> NM: there are some different approaches... start with a tight schema and loosen it, or the other way around. Plus, you can add new validation modes.
21:12:23 <DanC_lap> HT: I have stepped back a bit from this design, because the main use cases don't look so much like validation to me, but type assignment, i.e. databinding.
21:15:02 <DanC_lap> TBL: [... schemas and namespaces... scribe followed it, but then it leaked out before he got it recorded. sigh.]
21:16:14 <DanC_lap> TBL: suppose I'm doing schemas for composing SVG with XHTML, and the XHTML schema is immutable, say, because that WG is defunct...
21:16:43 <DanC_lap> HT: the XHTML modularization spec has cookbook examples for how to add forign-namespace elements anywhere?
21:17:08 <DanC_lap> TBL: so what would I put in an RDF schema to composing it with XHTML?
21:17:52 <DanC_lap> HT: the XHTML modularization spec has extension points... a group with no members [or something involving choices]...
21:19:22 <DanC_lap> HT: then, to add RDF, I make a new driver that points to the old driver plus adds RDF
21:20:08 <dorchard> q+ to as HT about extension elements and various writings on it.
21:20:51 <DanC_lap> TBL: how about doing it without a driver? i.e. by allowing the RDF schema to say "this is one of the things that are allowed in the XHTML head"?
21:21:12 <DanC_lap> HT: no, XHTML modularization isn't set up that way, and I _think_ that's the right decision
21:21:14 <DanC_lap> q+
21:22:16 <DanC_lap> NM: you can use lax/strict... but these look down, not up
21:25:15 <DanC_lap> [discussion of who controls which parts of the schema that the scribe is too interested in to record...]
21:25:27 <DanC_lap> q+ to note http://www.w3.org/XML/2000/04schema-hacking/
21:27:22 <DanC_lap> TBL: the XHTML schema could have types like: context free data, block, string/span
21:28:23 <DanC_lap> HT: so yes, you are talking about CDF... classes of semantic impact... yes, not unreasonable.
21:29:54 <DanC_lap> TV: yes, we [DSR and TV?] tried to make [this?] a completely extensible language... but we didn't manage to get a critical mass of support
21:30:28 <Vincent> s/[this?]/MathML
21:31:03 <DanC_lap> http://www.w3.org/XML/2000/04schema-hacking/
21:33:59 <DanC_lap> DC: I convinced myself XML Schema met the composability requirements timbl is laying out back in 2000/04. So I gather that yes, CDF is chartered to do that, but unfortunately we didn't design XHTML modularization that way.
21:34:28 <DanC_lap> TBL: yes, substitution groups; that sounds like what i'm after all.
21:38:24 <Norm> q?
21:38:31 <Norm> You want NVDL
21:39:36 <DanC_lap> TBL: so this what I'd like the W3C validator to do: parse it, (fix XML WF-ness), check the schemas, and report what your document has, e.g.: XHTML, SVG, and department of health diagramming component 12
22:18:10 <DanC_lap> .
22:18:10 <DanC_lap> .
22:18:10 <DanC_lap> .
22:18:19 <Vincent> ack dorchard
22:18:19 <Zakim> dorchard, you wanted to as HT about extension elements and various writings on it.
22:20:08 <DanC_lap> DO: on part I...
22:20:31 <DanC_lap> ... I worked on the terminology section... I worked over input from Mark D., ...
22:20:49 <DanC_lap> ... most of the changes are in the terminology sections... I worked over a bunch of stuff from Noah...
22:21:17 <DanC_lap> ... e.g. "text" vs "document" ...
22:22:12 <Noah> Noah has joined #tagmem
22:22:35 <Noah> I note that the version of the versioning finding linked from the findings page is the old version.  See: http://www.w3.org/2001/tag/doc/versioning.html
22:23:09 <Noah> The version that's named dangerously similarly http://www.w3.org/2001/tag/doc/versioning (note the clever omission of the .html) is up to date.
22:23:32 <Noah> I believe the correct version in date space is: http://www.w3.org/2001/tag/doc/versioning-20060929.html
22:23:52 <DanC_lap> DO fixes ACL on http://www.w3.org/2001/tag/doc/ext-vers-generic-uml-v5.png ...
22:24:40 <DanC_lap> DO: note arrows from Language to Syntax, to [... missed]
22:25:25 <DanC_lap> DO: extensibility is the difference between the defined text set and the accept text set
22:25:29 <Noah> Noah will want to go on the queue at the right time to suggest that defined vs. accept text set isn't the best way to slice this, but will hold off while Dave is reviewing all the changes.
22:25:55 <DanC_lap> DO: see also a page or two of new text under "Example 2: Evolution of Producers and/or Consumers"
22:28:20 <DanC_lap> q+ to follow up on "a middle name has no mapping to information"
22:28:25 <Noah> q+
22:29:41 <Noah> I think the formulation I'd prefer is (a) don't distinguish defined vs. accept text set (b) extensible languages are those that assign the same meaning to multiple texts -- later, when the languages are extended, those same texts may convey different meaning (e.g. the middle name may become significant.)
22:30:30 <Noah> I think I'd prefer that compatibility is covered by what Dave has that says:  Another precise form of compatibility is with respect to the information conveyed, that is whether the information conveyed by a text in one language is conveyed by the same text interpreted in another language. The texts could be compatible but the information conveyed is not compatible. For example, the same text could mean different and incompatible things in the different lang
22:30:49 <Noah> I like that.  Don't see why we need to go back to trying to explain which bits of syntax contribute which information.
22:34:27 <Norm> Editorial note: I assume ">=" is meant where ">" is used.
22:35:37 <Norm> Editorial note: in bullet 3: "T is in L1's set of Texts" which Text? Accept or Defined?
22:38:07 <DanC_lap> (somebody take a picture of the whiteboard and paste a pointer, please?)
22:38:28 <DanC_lap> (dave has it in a diagram in his laptop; maybe he'll mail it.)
22:44:15 <Norm> Whiteboard diagram: http://www.w3.org/2001/tag/2006/10/04-whiteboard-1.jpg
22:51:47 <DanC_lap> (oops... "another good example" should get recorded, but I'm a bit overloaded)
22:59:24 <DanC_lap> q+ to ask to walk thru L1 and L2 in a common/well-known case: HTML 2 to HTML 4
22:59:49 <ht_vancouver> q+ to offer a discussion about how to insulate the versioning story from the kinds of information issues that are derailing us in part
23:00:07 <timbl_> timbl_ has left #tagmem
23:00:09 <Norm> q?
23:00:26 <DanC_lap> ack danc
23:00:26 <Zakim> DanC_lap, you wanted to note http://www.w3.org/XML/2000/04schema-hacking/ and to follow up on "a middle name has no mapping to information" and to ask to walk thru L1 and L2 in a
23:00:29 <Zakim> ... common/well-known case: HTML 2 to HTML 4
23:00:53 <timbl> q?
23:05:28 <Norm> Editorial note: please use numbered lists instead of bulleted lists
23:07:54 <Norm> Editorial note: bullet 4 "Text T1 per" should be "Text T per"? T1 doesn't occur elsewhere
23:13:26 <timbl> q+
23:14:05 <Vincent> ack timbl
23:15:30 <DanC_lap> tune in to http://www.w3.org/2001/tag/2006/ext-vers/
23:16:48 <Noah> q-
23:22:54 <DanC_lap> DanC goes over the example in ex-html24.n3 and ext-vers-rules.n3 in the ext-vers/ directory. Confirms, to some extent, independent discovery of "the punch line"
23:24:16 <DanC_lap> the punch line in the current draft finding is [[ Language L2 is fully strictly compatible with Language L1 if L1 Accept Text set > (superset) Language L2 Accept Text set > (superset) L2 Defined Text set > (superset) L1 Defined Text Set AND every text in L1 Defined Text set is compatible with L2 AND every text in L2 Accept Text set is compatible with L1. ]]
23:25:16 <DanC_lap> TBL: for everything in the accept set that's not in the defined set, you have to say which element of the defined set it corresponds to.
23:26:57 <DanC_lap> NM: I think that only works for a subset of the languages we're interested in; in particular, ones where there's no "action at a distance", i.e. a change at the top affects the meaning of stuff at the bottom
23:27:51 <ht_vancouver> HST thinks Tim's point about mapping from texts in A-D to texts in D is a good one
23:28:56 <ht_vancouver> Because the interesting question wrt compatibility is the relationship, for things in L2 D but not L1 D, between I(M(T)) per L1 and I(T) per L2
23:29:06 <ht_vancouver> where M is Tim's mapping
23:29:47 <Vincent> q danc
23:30:04 <Vincent> q+ DanC
23:33:05 <Vincent> ack ht
23:33:05 <Zakim> ht_vancouver, you wanted to offer a discussion about how to insulate the versioning story from the kinds of information issues that are derailing us in part
23:36:52 <timbl> Ra,in:   This is wher eyou get partial ordring and lattices.
23:37:03 <Noah> TVR: When you have D1, for things outside D1, they map to equivalence classes.  Call that partition E1.
23:37:29 <Noah> TVR: When you have L2, you get another set of equivalence classes.  Call that set E2.
23:37:47 <Noah> TVR:  E1 and E2 have partial order and form a lattice.
23:38:20 <Noah> NM: (I had said earlier, you need also to tell a story not only about the point that wound up in D2, but also all the things in its equivalence class per L2)
23:38:44 <Noah> NM: (said earlier) I think I prefer to talk about equivalence classes vs. a canonical.
23:39:08 <Noah> TBL (said earlier) the difference between equivalence classes and talking about canonicals is not interesting.
23:39:31 <Noah> DO: When you project into D1, you lose the stuff that doesn't contribute significant information into I1
23:40:03 <Noah> HT: Tim suggested there is an equivalence class of text in A-D1.  They all correspond to canonical.
23:42:44 <Noah> TVR: Suggest a physical visualation. Instead of concenrtric circles, imagine a bowl that widens at a top.  Draw circles centered on the center of the bowl.  The equivalence classes are demarcated by veritcal lines.
23:42:53 <Vincent> ack danc
23:44:28 <Noah> DC: (we are projecting the diagram from the finding that shows Text Set, and hanging from it a box Defined text set and Accept text set.
23:45:13 <Noah> DC: I'd prefer a picture  that shows two boxes, one labeled language, the other text set.  There are two arrows, both sourced at lang and terminating at text set.
23:45:24 <Noah> DC: One is labeled defined set, the other labeled text set.
23:46:08 <Noah> HT: But we lose the subset relationship.
23:46:58 <Noah> TBL: Another way to look at it.  There are two langs.  E.g. for HTML2, we map the defined texts onto interpretations.  We can say there is the strict language and the lax.
23:47:50 <Noah> HT: You don't get to pick the canonical.  It defines the equivalence class.
23:53:42 <Noah> TBL: Two things in D can have different syntax and same meaning,e.g. single and double quotes on attributes.
23:58:03 <DanC_lap> (re whitespace in XML, people are still getting bitten by the way newlines in attributes disappear... http://golem.ph.utexas.edu/~distler/blog/archives/000564.html )
23:58:49 <DanC_lap> (I read it this week; I guess it was written a year ago. Still, a long time since whitespace rules in XML were decided.)