14:08:00 <RRSAgent> RRSAgent has joined #tagmem
14:08:00 <RRSAgent> logging to http://www.w3.org/2008/09/25-tagmem-irc
14:08:48 <Ashok> DaveO:  Summarizes cover note
14:11:16 <Norm> Diff: http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-080602-080912-diff.html
14:11:58 <Ashok> DaveO:  I think option 3 is best.  We shd allow digest authentication 
14:13:54 <Zakim> -Norm
14:13:56 <Zakim> -??P12
14:13:57 <Zakim> TAG_f2f()10:00AM has ended
14:13:57 <Zakim> Attendees were Norm
14:14:05 <ht> ht has joined #tagmem
14:15:29 <noah> noah has joined #tagmem
14:15:51 <Ashok> TimbL:  Norm, the GRDDL and stylesheet changed for yr document
14:16:07 <Ashok> The action is almost done.
14:16:43 <timbl> s/Norm/No*/
14:17:40 <Ashok> ht:  I like 2
14:18:10 <Ashok> TimbL:  can we can clear text almost always bad, digest is better.  All have problems
14:18:40 <Ashok> Dave:  We will get push back from sec WG
14:19:38 <Ashok> Noah:  Different usecases
14:19:43 <Stuart> q?
14:19:53 <Ashok> Noah:  The word 'ok' is not ok
14:20:14 <timbl> I suggest discussion by suggetsion of lternate text
14:20:27 <jar> q+ re 'not without risk'
14:21:06 <timbl> Clear text passwords are a serious security risk,though sometimes are acceptable.   
14:21:07 <raman> raman has joined #tagmem
14:21:26 <Norm> The question is: do we want to write something that's about policy or pragmatics?
14:21:49 <Ashok> Stuart:  We are talking abt technoligies rather than priciples
14:21:50 <DaveO> I think pragmatics...
14:21:54 <noah> I find the work "ok" confusing.  There are scenarios where it's not OK.  There are scenarios where I think it's sort of borderline OK, depending which issues you worry about.
14:22:18 <noah> If you ask: can Noah put up a web site for his family and assign simple clear text passwords?  Yes, I don't think that's a disaster.
14:22:19 <jar> i like that the draft as is where uses the wording 'x is not without risk'   ... this seems better than any kind of 'should' or 'ok'
14:22:35 <noah> Should he really warn all family members to never, ever use for that site the same password they use for banking? Yes.
14:22:57 <timbl> Clear text passwords are a serious security risk,though sometimes are acceptable.   Digest authentication has significant advantages over clear test passwords, though other security issues arise.  The use of an encrypted channel or key exchange is always more secure.
14:23:06 <Ashok> Raman:  We are saying MUST and SHOULD abt things we have no control over
14:23:10 <timbl> q+
14:23:37 <ht> q+ to endorse TV's suggested change of rhetorical approach
14:23:46 <noah> Is there a risk that some family member won't get the message? Yes.  Is the risk that the family member will do that, that someone will sniff their network just while accessing the family site, and then break into the bank account high enough to worry about?  Not necessarily in all circumstances.  So, that justifies three, but you probably have to discuss those tradeoffs.
14:23:55 <Ashok> jar:  I liked the stmt that doing ...  is not without risk
14:24:16 <Stuart> q?
14:24:20 <timbl> ack jar
14:24:20 <Zakim> jar, you wanted to comment re 'not without risk'
14:24:28 <Ashok> jar:  Function of what threats you are trying to protect against
14:24:44 <DanC_lap> ack tim
14:24:46 <Stuart> ack tim
14:25:27 <noah> q+ to suggest Tim's approach, but with examples.
14:25:30 <jar> My specific wording: Simply strike the two 'good practice' boxes in section 2. The TAG's position is simply the following sentence" There are no scenarios where ..."
14:25:40 <Ashok> Timbl:  discusses his suggested text above
14:25:57 <Stuart> q+
14:26:07 <DanC_lap> hmm... "always more secure"... darn; can't think of a replacement
14:27:28 <Ashok> Dave:  We could not get to consensus on the good practive notes.
14:27:53 <Ashok> TimBl:  You can use my text to wtite good practice notes.
14:28:04 <Ashok> Timbl:  You can also tell stories
14:28:12 <DanC_lap> (what timbl said about "here's software you can download..." reminds me that somebody claimed victory on password management with the release of some software...)
14:29:01 <Ashok> Dave:  I can work this in during the break
14:29:02 <DanC_lap> (darn; looks like I didn't bookmark it.)
14:29:11 <timbl> q?
14:29:30 <Stuart> ack ht
14:29:30 <Zakim> ht, you wanted to endorse TV's suggested change of rhetorical approach
14:30:01 <Ashok> ht:  Trying to frame things as advice is sensible.  Can be couched as good practice
14:30:17 <timbl> (I suspect that someone has probably packaged and patented your hash-based password management system, dan! :)   )
14:30:37 <Stuart> ack Noah
14:30:37 <Zakim> noah, you wanted to suggest Tim's approach, but with examples.
14:31:01 <Ashok> Noah: I think we shd either kill or publish this
14:31:16 <Ashok> Noah:  Shd add some stories
14:32:15 <DanC_lap> (re 3rd party, is "the transitive property of insecurity" by tchrist the canonical work? or do I just know it because I worked with tchrist at convex?)
14:32:34 <Ashok> Noah:  outlines some failure modes
14:33:26 <Stuart> ack me#
14:33:39 <jar> +1 to what noah is saying. purpose of document should ideally be to teach people about risks they may not have thought about
14:34:11 <Ashok> skw:  one risk is users reuse passwords.  We don't say this
14:34:27 <Ashok> skw:  We are trying to educate naive users
14:34:32 <timbl> q+ to suggest references
14:34:53 <Ashok> Dave:  I can come up with some stories
14:35:21 <Ashok> skw:  Weak passwords cause poblems
14:36:10 <Ashok> skw:  These are not sensetive.  The principle is not exposing sensetive info in the clear
14:36:34 <Ashok> TimBl:  Cannot divide into 2 groups.  It's a continuum
14:37:15 <Stuart> q?
14:37:24 <Stuart> q-
14:37:28 <Stuart> ack timbl
14:37:28 <Zakim> timbl, you wanted to suggest references
14:38:02 <Ashok> TimBl:  we shd put specific references to stories, academic discussions, security papers
14:38:37 <Ashok> skw:  Security context WG would be open to meeting with us
14:39:23 <Ashok> ht:  Trying to shift tone to advice rather than normative statements backed up with some stories
14:39:42 <Ashok> jar:  Why is this a tag issue, historically?
14:39:59 <Ashok> TimBl:  We advise people how to run servers
14:40:16 <Ashok> Dave:  Some tag member felt passionately abt this
14:40:26 <timbl> See for example http://en.wikipedia.org/wiki/Digest_access_authentication#Disadvantages
14:41:18 <Ashok> skw:  He wanted some levers to beat browser mfgs with
14:42:09 <noah> q?
14:42:44 <Ashok> TimBl:  We talked to security experts.  They were horrified we recommended digest authentication
14:42:58 <Ashok> TimBl:  They work at the high end
14:43:41 <Ashok> Noah:  They had 'just say no' appoach.  Their users were a diverse group.
14:44:39 <Ashok> TimBl:  World would be safer is people just moved to digest authentication by flipping a few bits
14:46:42 <Ashok> Dave:  I can fix the words as Tim suggested and add references
14:46:55 <DanC_lap> (found the origin of the issue... it was in a discussion of DIX http://www.w3.org/2006/04/18-tagmem-minutes#item06 )
14:47:32 <Ashok> skw:  Let's go thru the diffs
14:48:59 <Ashok> No objection to changes in 2.1.1
14:50:01 <DaveO> there is no standard way of
14:50:01 <DaveO> performing a salting/digesting mechanism? The User-agent and the server
14:50:01 <DaveO> will have to agree on the exact data and algorithm via some non-standard
14:50:01 <DaveO> out-of-band mechanism - which goes beyond the provisions of
14:50:01 <DaveO> HTTP Digest Auth mechanism as defined in RFC 2617.
14:50:20 <Ashok> Noah:  Can we add these sentences?
14:50:40 <DaveO> This makes me think that if the requirement is that a user-agent MUST 
14:50:40 <DaveO> NOT transmit a password in the clear, then the server MUST NOT store 
14:50:40 <DaveO> cleartext passwords or the server MUST use SSL/TLS. Ultimately, that is 
14:50:40 <DaveO> where the Web should be headed. Tricky thing to say though ;)
14:53:23 <Norm> I'm fine with Dave's edits.
14:53:40 <Ashok> No objections tochanges in 2.1.3
14:56:10 <DanC_lap> (wierd... the link from the agenda takes me to a June draft, with no section 4. I think I read the wrong draft)
14:57:34 <Ashok> Ashok/Dan:  Add references to new security technologies
14:58:07 <DanC_lap> cite http://openid.net/specs/openid-authentication-1_1.html May 2006
14:58:42 <Ashok> No objection to changes in section 4
14:59:01 <Ashok> jar:  I have 5 editorial changes.  I will mail them to you
14:59:01 <Stuart> q?
14:59:44 <DanC_lap> and cite http://oauth.net/core/1.0/ Dec 2007 "OAuth Core 1.0"
15:03:50 <DanC_lap> hard to find a good reference for SAML. best I can find is http://www.oasis-open.org/specs/#samlv1.1 August 2003
15:04:02 <DanC_lap> ... Security Assertion Markup Language (SAML) v1.1 [OASIS 200308]
15:33:25 <DaveO> http://www.w3.org/2001/tag/doc/versioning-compatibility-strategies-080520-080917.html
15:33:27 <Ashok> Topic: XMLVersioning-41
15:34:43 <Ashok>  Versioning diff: http://www.w3.org/2001/tag/doc/versioning-compatibility-strategies-080520-080917.html
15:36:27 <Ashok> DaveO:  Runs thru diffs since 5/20
15:38:42 <Ashok> Section 1.2 bullet 4
15:39:09 <Ashok> CSS 2.1 was a subset of 2 with features people actually used.
15:40:10 <DanC_lap> (the diff is from which draft?)
15:40:13 <raman> q+ to remark on css bits 
15:40:28 <Ashok> Changed definitions of forwards and backwards compatible
15:41:57 <DanC_lap> q+
15:42:46 <Ashok> Noah:  This is a relation between 2 specs.  Why are consumers in this?
15:43:11 <Ashok> jar:  Its a relation between producers and consumers
15:45:40 <Ashok> Some members signal approval of text
15:47:55 <Stuart> q?
15:48:01 <Stuart> q?
15:48:13 <Stuart> ack raman
15:48:13 <Zakim> raman, you wanted to remark on css bits
15:48:58 <Ashok> raman:  CSS text goes away from what the document says.  CSS says 'no versioning'.
15:49:15 <Ashok> This doc talks abt major/minor version numbers
15:49:41 <Ashok> DaveO:  Doc does not require version identifiers
15:51:04 <DanC_lap> (the css vendor prefixes... moz-3d-margin sure looks more like <apple:canvas> than <canvas>. hmm.)
15:51:16 <Ashok> DaveO:  Doc discusses how CSS allows extensibility -- compatible versioning strategy
15:52:08 <Ashok> ht:  There are people who love CSS versioning and some hate is
15:52:16 <DanC_lap> q+ to think out loud about <apple:canvas>/<canvas> and -moz-3d-margin
15:53:56 <Ashok> DaveO:  CSS has implicit contract not to introduce backwards incompatibility 
15:54:11 <Ashok> Noah:  That's worth talking about
15:54:25 <Stuart> ack dan
15:54:25 <Zakim> DanC_lap, you wanted to think out loud about <apple:canvas>/<canvas> and -moz-3d-margin
15:57:03 <Ashok> Discussion abt how CSS evolves
15:57:38 <DanC_lap> TimBL: the vendor prefix results in stylesheets with 4 declarations -moz-rounded-corner and rounded-corner and so on. The validator blows up...
15:58:39 <Ashok> jar:  Use Wikipedia as registry
15:58:54 <DanC_lap> DanC: well, yes, I see all those costs, but I hear positive things about balance of vendor influence on the standards in css with vendor prefixes
15:59:04 <DanC_lap> TVR: well, some people are happy...
15:59:58 <Ashok> TVR:  I would like some mods to CSS story
16:00:09 <Ashok> DaveO:  Not got to it yet
16:01:21 <Ashok> Section 2.1.1
16:02:23 <Ashok> Includes some text abt benefits of version identifiers and some new stuff abt CSS
16:03:26 <Ashok> typo in Good Practice
16:04:50 <Ashok> remove 'excellent'
16:05:26 <Ashok> Dan: Need example of where version numbers worked
16:08:55 <timbl> q+
16:09:03 <Ashok> Noah:  Version identifiers may be mixed blessing
16:09:57 <Ashok> TimBl:  Lets tell the sories.  Tell the Babble story including the TECO parts
16:10:04 <DanC_lap> (oops; I only meant to suggest changing the order of the paragraphs. )
16:10:19 <DanC_lap> (the text is acceptable to me as is, once "excellent" is struck.)
16:10:34 <Ashok> Say that CSS does not use versions and there is controversy abt this
16:10:49 <Ashok> DaveO:  It now has stories 
16:11:04 <Ashok> TimBl:  Let's not generalize from stories 
16:14:11 <Norm> Ring ring
16:15:09 <Ashok> skw:  'may be a side benefit' is weak.  say 'a benefit'
16:15:18 <DaveO> A benefit of having no version identifiers is...
16:15:48 <Ashok> Dan:  Would prefer CSS later.  
16:16:07 <DaveO> rewrite the double because sentence
16:16:28 <Ashok> Noah:  Editorial- rewrite sentence with 2 becauses
16:17:47 <Ashok> ht:  Do the negatives come later on?
16:18:29 <Ashok> DaveO:  Problem is to specify meaning of version identifiers
16:18:56 <Ashok> Noah:  Do we have success stories on version identifiers?
16:19:05 <Ashok> ht:  XSLT
16:19:15 <Stuart> q?
16:19:41 <timbl> q-
16:21:49 <Ashok> raman:  EXSLT work is good example 
16:22:13 <Ashok> TimBl:  Is it in wide use
16:22:27 <Ashok> Raman:  Yes, it's very successful
16:24:03 <Ashok> Editorial:  'it is may be'
16:24:37 <Ashok> Noah:  Could split into 3 paras
16:25:13 <Ashok> Editorial 'the which'
16:26:57 <DanC_lap> (Dave, I prepared more on section 5, as we discussed when putting the reading list together. Is it awkard to skip there?)
16:28:40 <DaveO> should specify how and where any version identifiers can occur and the meaning..
16:28:48 <Ashok> jar: one question is shd there be version ids
16:29:04 <Ashok> related question is what to do with version ids
16:32:21 <DaveO> you should be explicit about the version identifier strategy.
16:35:03 <Ashok> Good Practice:  "Any languages intended for versioning "   is misleading
16:35:16 <DaveO> languages intended for versioning -> languages that are intended to be versioned 
16:36:07 <DaveO> or intended to evolve...
16:36:26 <DaveO> Languages should specify the meaning of any version identifiers
16:38:34 <timbl> In 5.2 th content of OBJECT might be a better example than the @alt attribute
16:39:08 <timbl> maybe not
16:40:58 <Ashok> DaveO:  Let's skip to section 5
16:42:37 <DaveO> "good example" -> "example"
16:43:10 <DaveO> "this is a good example", what "this"?
16:44:49 <DaveO> in the xml language, add "itself"
16:45:27 <Ashok> jar:  use of data: is dangerous in light of our discussion on separation of concerns
16:46:34 <DanC_lap> good catch, jar.
16:46:38 <DaveO> Change HTML not extensible to forms or tables
16:46:57 <Ashok> jar: use different example
16:47:09 <Ashok> daveo:  forms or tables
16:49:56 <Ashok> raman:  Ignore unrecognized element was a bad example -- ties yr hands
16:50:36 <Ashok> does not give you extensibility and forces people to use attributes because attributes are not rendered
16:52:26 <Ashok> TimBL:  This was great for adding cite: and ... but was bad for adding script
16:53:16 <DaveO> Add a forward reference to ignore all or part...
16:53:33 <Ashok> TimBL:  i leked the bit about mapping from language you don't understand to what you do understand.
16:53:53 <Ashok> s/i leked/I liked/
16:54:04 <DanC_lap> ... for extensibility; unknown tags were ignored.
16:54:28 <DaveO> "may be encountered" add "and should be ignored"
16:55:00 <DanC_lap> dave, my edit (2 lines up) makes the sentence shorter.
16:55:03 <DanC_lap> not critical.
16:58:22 <Ashok> TimBl:  Does it tell the XML story?
16:59:16 <Ashok> Thev rqeuirement that if you don't understand the version Id you stop made it hard to create new versions
16:59:31 <Ashok> s/Thev/The/
17:05:53 <Ashok> TimBl:  Story is migration to XML 1.1 failed.  We ended up adding the changes to 1.o without changing the version number
17:06:17 <Ashok> c/1.o/1.0/
17:08:04 <Ashok> Fourth para after section 5
17:08:38 <Ashok> XML could have provided fallback strategy
17:12:07 <Ashok> Discussion about XML extensibility
17:13:23 <Stuart> From http://www.w3.org/TR/2000/REC-xml-20001006: "The version number "1.0" should be used to indicate conformance to this version of this specification; it is an error for a document to use the value "1.0" if it does not conform to this version of this specification. It is the intent of the XML working group to give later versions of this specification numbers other than "1.0", but this intent does not indicate a commitment to produce any future versions of XML, 
17:14:21 <timbl> q+
17:14:35 <Ashok> Noah: ... all the texts that may be accepted by later versions are accepted in the first version in some way
17:15:38 <Ashok> TimBl:  For example ignore ....
17:17:28 <timbl> q+
17:20:02 <Ashok> hange 'infinite' to unbounded'
17:21:07 <Ashok> s/hange 'infinite'/change 'almost infinite' to 'unbounded'/ 
17:21:34 <DaveO> XML was not as extensible...
17:21:45 <DaveO> ?
17:22:35 <DaveO> the XML language is much less extensible than HTML.
17:23:21 <DaveO> is is usable to create..
17:25:23 <Ashok> Finished discussion upto start of 5.1
17:26:48 <Ashok> rrsagent, make logs public
17:54:22 <Stuart> Stuart has joined #tagmem
18:31:30 <DaveO> norm, are you there?
18:31:52 <Norm> yes
18:33:10 <DanC_lap> RESOLVED: to thank the Kauffman foundation for hosting us. with applause.
18:36:56 <noah> noah has joined #tagmem
18:37:14 <DanC_lap> Zakim, take up item 1
18:37:14 <Zakim> agendum 1. "XMLVersioning-41" taken up [from DanC_lap]
18:37:58 <DaveO> did you want to dial in?
18:38:29 <DaveO> probable regrets for in person attendance at dec f2f
18:38:48 <Norm> yep. be right there.
18:38:54 <DanC_lap> scribe: DanC
18:39:49 <DanC_lap> DO: made some edits just now...
18:42:09 <Norm> -> http://www.w3.org/2001/tag/doc/versioning-compatibility-strategies-diff-080520-080925.html
18:44:34 <DanC_lap> DO: note updates in section 5...
18:45:48 <DanC_lap> NDW: hmm... XML 1.0 5ed sheds new light on that para about XML extensibility
18:48:26 <timbl> s/s/is/
18:48:33 <timbl> (in the text!)
18:49:30 <timbl> change "scripts"  "the <script> tag"
18:49:46 <DanC_lap> NDW: the edits to these 2 paras are an improvement
18:49:53 <DanC_lap> DC: yeah; I'm ready to move on
18:50:05 <timbl> change "some types of extensions" to "some types of extensions such as th <cite> and <tt> tags"
18:50:18 <timbl> change "some types of extensions" to "some types of extensions such as th <cite> and <tt> markup tags"
18:50:47 <timbl> change "almost unbounded" to "unbounded"
18:51:35 <timbl> delete "as attempted by xml 1.1"
18:51:54 <timbl> (It was not that issue which prevented xml1.1 from working)
18:53:14 <DanC_lap> DanC: the "Good practice" label seems wrong; these are design choices, not things we expect every design to follow, right?
18:53:22 <DanC_lap> DO: well, not in the 1st case in 5.1
18:54:02 <DanC_lap> q+ to suggest dropping the 1st box
18:54:58 <DanC_lap> ack danc
18:54:58 <Zakim> DanC_lap, you wanted to suggest dropping the 1st box
18:59:25 <DanC_lap> tbl example: <p> <foo> hello world <i>!</></foo> </p>
19:02:35 <DanC_lap> (diversion into the history of HTML ...)
19:03:36 <DanC_lap> (ah... dave's memory is better than mine...
19:03:37 <DanC_lap> "HTML user agents supports a superset of the HTML 2.0 language by
19:03:37 <DanC_lap>    reducing it to HTML 2.0: markup in the form of a start-tag or end-
19:03:37 <DanC_lap>    tag, whose generic identifier is not declared is mapped to nothing
19:03:37 <DanC_lap>    during tokenization."
19:03:38 <DanC_lap> )
19:03:55 <DanC_lap> -- http://ftp.ics.uci.edu/pub/ietf/html/rfc1866.txt
19:05:28 <DanC_lap> TVR: ...
19:05:42 <DanC_lap> JAR: this is exactly what Lisp did in 1962: separate read from eval
19:07:28 <DanC_lap> [there was an analogy to HTML 5 parse-to-dom and do-stuff-with-dom]
19:08:41 <timbl> q+
19:11:03 <DanC_lap> NM: is this it? language specifications may provide for 2 flavors of forward compatibilty: (1) clients ignore... (2) clients preserve...
19:11:07 <DanC_lap> DO: yes, something like that
19:12:34 <raman> TVR: what I said: we've talked about various axies along which the html5 specification could be modularized; one reasonable way to think of it might be to separate out serialization/desiralization to the DOM (including error recovery, evaluating document.write etc)  i.e. up to the point where a DOM is built; specify newer constructs e.g. video element, purely in terms of the DOM.
19:13:09 <timbl> q+
19:13:22 <raman> Rules for serializing the DOM could then  be consistently applied to this constructed DOM --- would avoid syntactic errors from the past perculating into  how newer elements/constructs are authored.
19:13:31 <timbl> q+ to point out that "accept abnd preseve" des not apply generally to arbitrary languages, only to marku.
19:15:13 <DanC_lap> SKW: trying to understand these rules... they're choices to adopt or not?
19:15:26 <DanC_lap> DO: I think so...
19:16:38 <DanC_lap> HST: hmm... rules with SHOULD etc... isn't the rule just "accept and discard any portion you don't recognize"
19:17:02 <Ashok> Ashok has joined #tagmem
19:17:03 <DanC_lap> TBL: these are phrased imperatively, yes?
19:17:06 <DanC_lap> HST: yes...
19:17:51 <DanC_lap> HST: you could say things like "a processor is forward-compatible-happy if it does rule-X or rule-Y"
19:18:36 <DanC_lap> HST: consider "text portions that are not in the defined set are accepted and discarded"
19:19:06 <DanC_lap> HST: though 'defined set' is perhaps the wrong generation of terminology
19:20:25 <DanC_lap> (re "rule" ... brainstorming... "design pattern" or "design choice")
19:20:36 <ht> or 'strategy'
19:20:50 <DanC_lap> +1 strategy
19:21:01 <DanC_lap> TBL: strategy is something can adopt or not. good idea.
19:22:26 <DanC_lap> (is "strategy" actually already used? this is a question of fact)
19:22:56 <DanC_lap> DO: it's awkward to have forward-compatibility strategies built from strategies.
19:23:04 <timbl> (strategy is used)
19:23:08 <DanC_lap> (where?)
19:23:21 <Stuart> fwiw: forward compat or backward compat etc are design goals for or propreties of a language.
19:23:42 <timbl> (... For example, many W3C languages adopt a strategy of allowing incompatible changes in Working Drafts ...)
19:24:36 <DanC_lap> DO: acceptable to go with "rule" and take the SHOULDs out?
19:24:39 <DanC_lap> DC: yes
19:24:40 <DanC_lap> AM: yes
19:25:02 <Stuart> These 'rules'/'practices' are things that can be used to accomplish compatibility goals.
19:25:37 <DanC_lap> TBL: or a different style.
19:25:39 <DanC_lap> DO: ok.
19:25:49 <DanC_lap> ack timbl
19:25:49 <Zakim> timbl, you wanted to point out that "accept abnd preseve" des not apply generally to arbitrary languages, only to marku.
19:25:50 <Stuart> q?
19:28:17 <DanC_lap> TBL: the notion of "preserve" is explained as though it applies to all languages, but for languages like C/perl, it makes no sense.
19:28:53 <DanC_lap> DC: hmm... seems to make sense to me.
19:29:13 <DanC_lap> TBL: what does it mean for an HTTP server to 'preserve' a header?
19:29:26 <DanC_lap> ... yes, it makes sense for proxies, but what about origin servers?
19:29:41 <DanC_lap> NM: logging, for example
19:30:11 <DanC_lap> DO: what the text says is that the HTTP language follows both the preserve rule and the ignore rule
19:32:21 <DanC_lap> DC: only starting to understand this concern, Tim; does a suggested change occur to you?
19:32:32 <DanC_lap> TBL: hmm... no... maybe ok to let it go
19:32:58 <DanC_lap> s/makes no sense/makes no sense. The input and output of a C compiler aren't of the same type./
19:33:15 <DanC_lap> DO: I see that the presentation of the rules needs work.
19:33:45 <DanC_lap> .
19:33:46 <DanC_lap> .
19:33:55 <DanC_lap> DO: let's look at 5.3 Version Identifiers
19:36:06 <Stuart> re 5.3: suggest s/Two of more the popular ones follow:/Two popular models follow/
19:36:26 <DanC_lap> NM: is this stuff about version identifiers only about forward compatibility
19:36:33 <DanC_lap> agenda+ wrap up on HTML
19:37:00 <DanC_lap> NM: is this stuff about version identifiers only about forward compatibility?
19:37:18 <DanC_lap> DC: note section 5 is all about forward compatiblity
19:37:42 <DanC_lap> NM: then append "... for Forward Compatibility" in the label of 5.3, pls
19:39:50 <DanC_lap> (my sympathy with the "don't generalize so much from the stories" comment grows.)
19:40:29 <DanC_lap> DC: I read this box too quickly; now that I look again, I'm struggling to make sense
19:42:07 <DaveO> Need to update 5.3 to change "producer understands" to "documents that are compatible with".
19:42:52 <DaveO> and provide back ref
19:43:54 <jar> 5.3.1 Please either define "valid" or use some other term
19:44:29 <DanC_lap> (where, jar? ah... "A text may contain a version identifier for texts that are valid under multiple versions" )
19:45:03 <DanC_lap> NM: ... default model... what's that?
19:45:23 <jar> (thinking aloud) When a producer provides a version identifier in a text, it is asserting something about the rest of the text.
19:45:58 <DaveO> some mix ups around "default model" "handling model" "processing model"
19:46:09 <DaveO> "interpretation model"
19:46:20 <jar> Maybe it's saying: The (rest of) the text can be, and is supposed to be, interpreted/processed according to the language version named by the identifier
19:47:18 <DanC_lap> evidently not.
19:47:48 <jar> Then the consumer has to draw its own conclusion, according to the language family's versioning strategy.
19:48:40 <DaveO> default model for identifiers does not tie structure of identifiers.
19:49:14 <jar> Only consumers need to know about x.y - the producers don't. (why would they say version 2.4 when they only know about version 2.3? even if policy says that 2.3 texts are interpreted in 2.4 the same as in 2.3?)
19:50:08 <jar> (that was continued thinking aloud)
19:50:52 <DaveO> need to redo 5.3.1 gpn.
19:51:20 <Stuart> Try something like: "Systems of version identification should define their model of indicating compatible/incompatible change and for establishing an ordering relation between versions"
19:51:45 <Stuart> q?
19:51:52 <DaveO> languages should specify the meaning of the structure of identifiers wrt compatible/incompatible evolution.
19:52:49 <DanC_lap> AM: w.r.t. "HTML handled unknown version numbers in a forwards compatible way because browsers ignored the version numbers they didn't understand." was it the numbers or the documents they ignored?
19:52:52 <DanC_lap> DO: the numbers
19:54:05 <Stuart> 5.3.1 3rd para begins "Then... " without an antecedent upon which the consequent depends.
19:56:59 <DanC_lap> DO: gpn should be something like...
19:57:21 <DanC_lap> ... when texts will contain the highest. --
19:57:54 <DanC_lap> NM: when a language specification uses the strategy that documents will be labelled with the highest version...
19:58:16 <DanC_lap> HT: this is just "authors write the version number they use"
19:58:25 <DanC_lap> NM: it's more than that...
19:58:45 <DanC_lap> NM: some of this strategy is... this is leading toward major/minor
19:59:27 <DanC_lap> (darn; several seems to get it, but I couldn't follow well enough to write it down)
20:01:42 <DanC_lap> -Norm
20:02:40 <DanC_lap> --- break ---
20:11:26 <Stuart> agenda
20:11:34 <Stuart> agenda?
20:11:54 <Stuart> agenda+ Pw
20:12:40 <Stuart> drop agenda item 5
20:13:07 <Stuart> agenda+ PasswordsInTheClear
20:14:48 <Stuart> agenda?
20:14:59 <DanC_lap> agenda -5
20:15:16 <DanC_lap> agenda 5 = PasswordsInTheClear [Stuart]
20:15:18 <DanC_lap> agenda -6
20:15:23 <DanC_lap> Zakim, close item 1
20:15:23 <Zakim> agendum 1, XMLVersioning-41, closed
20:15:24 <Zakim> I see 4 items remaining on the agenda; the next one is
20:15:25 <Zakim> 2. binaryXML [from DanC_lap]
20:15:31 <DanC_lap> Zakim, agenda?
20:15:31 <Zakim> I see 4 items remaining on the agenda:
20:15:32 <Zakim> 2. binaryXML [from DanC_lap]
20:15:33 <Zakim> 3. self-describing web [from DanC_lap]
20:15:34 <Zakim> 4. wrap up on HTML [from DanC_lap]
20:15:35 <Zakim> 5. PasswordsInTheClear [Stuart]
20:17:00 <DanC_lap> agenda 1 = XMLVersioning-41
20:17:05 <DanC_lap> Zakim, agenda?
20:17:05 <Zakim> I see 5 items remaining on the agenda:
20:17:06 <Zakim> 1. XMLVersioning-41
20:17:06 <Zakim> 2. binaryXML [from DanC_lap]
20:17:07 <Zakim> 3. self-describing web [from DanC_lap]
20:17:08 <Zakim> 4. wrap up on HTML [from DanC_lap]
20:17:10 <Zakim> 5. PasswordsInTheClear [Stuart]
20:17:22 <DanC_lap> agenda order is 4, 2, 1, 3, 5
20:17:34 <DanC_lap> Zakim, next item
20:17:34 <Zakim> agendum 4. "wrap up on HTML" taken up [from DanC_lap]
20:18:10 <DanC_lap> q+ ht
20:18:16 <DanC_lap> ack ht
20:19:36 <DanC_lap> HT: about TPAC... next telcon is probably too late to start setting up a meeting
20:19:48 <DanC_lap> SKW: I've heard concerns ...
20:19:55 <DanC_lap> DC: plan optimistically?
20:20:46 <DanC_lap> . ACTION: Stuart contact HTML WG chairs about TPAC possibilities
20:21:58 <DanC_lap> ACTION: Stuart contact HTML WG chairs about TPAC possibilities... spec modularization, etc.
20:21:58 <trackbot> Created ACTION-179 - Contact HTML WG chairs about TPAC possibilities... spec modularization, etc. [on Stuart Williams - due 2008-10-02].
20:23:12 <DanC_lap> HT: thinking about ways to organize the HTML 5 spec into parts... the idea of parser vs object model ...
20:24:06 <DanC_lap> ... in the schema spec, that doesn't work, because the mapping from infoset to object model is interconnected; we tried it that way and it didn't work.
20:25:21 <DanC_lap> HT: I'm more interested a split between language definition and error correction
20:25:48 <DanC_lap> (in passing, I think the split around dom is feasible; it's the way the spec is currently organized, more or less)
20:34:55 <DanC_lap> discussion of agenda planning around HTML...
20:40:17 <DanC_lap> Zakim, next agendum
20:40:17 <Zakim> agendum 2. "binaryXML" taken up [from DanC_lap]
20:41:35 <DanC_lap> HT: I'll send my minor comments individually...
20:43:01 <DanC_lap> ... but each of the 1st 3 paras in [see minutes earlier] are issues I think the TAG should agree whether to comment on
20:47:17 <DanC_lap> (tbl refers to self-describing web ... rrs action june )
20:50:45 <DanC_lap> (see flip-chart photo from skw's machine. @@)
20:52:09 <DanC_lap> TBL: [... missed... ]
20:52:18 <DanC_lap> HT: yes, we could do that, but...
20:52:36 <DanC_lap> ... neither @@1 nor @@2 wants generic XML processors to process EXI...
20:52:53 <DanC_lap> ... the target is that there are separate stacks until you get to the infoset
20:53:08 <DanC_lap> s/@@1/the EXI community/
20:53:13 <DanC_lap> s/@@2/the XML community/
20:54:07 <DanC_lap> NM: another concern is w.r.t. branding
20:54:28 <DanC_lap> ... i.e. don't upset expectations that XML mostly just works
20:56:11 <DanC_lap> HT: so this argues for "(a) TAG should endorse it and (b) EXI WG should ack the kludge"
20:57:03 <DanC_lap> HT: ... "doesn't achieve byte-for-byte fidelity even for XML docs"
20:59:06 <DaveO> Norm generated: http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-080912-080925-diff.html
21:00:00 <ht> ACTION: Henry to write to EXI WG wrt EXI Best Practices of 2007-12-19 saying that, presuming the draft still reflects their intent, the TAG is happy, but would like a more explicit statement of the 'fudge' involved in treating EXI as a Content Encoding
21:00:00 <trackbot> Created ACTION-180 - Write to EXI WG wrt EXI Best Practices of 2007-12-19 saying that, presuming the draft still reflects their intent, the TAG is happy, but would like a more explicit statement of the 'fudge' involved in treating EXI as a Content Encoding [on Henry S. Thompson - due 2008-10-02].
21:00:23 <DanC_lap> ADJOURN.
21:15:09 <DaveO> file:///Users/davidorchard/Documents/Eclipse/doc/versioning-compatibility-strategies-20080925.html
21:18:59 <timbl> http://lists.w3.org/Archives/Public/www-tag/2008May/0155.html
21:49:03 <Stuart> cation jar update versioning formalism to align with terminology in versioning compatibility strategies
21:49:13 <Stuart> action jar update versioning formalism to align with terminology in versioning compatibility strategies
21:49:13 <trackbot> Created ACTION-181 - Update versioning formalism to align with terminology in versioning compatibility strategies [on Jonathan Rees - due 2008-10-02].
21:49:39 <Stuart> trackbot, status
21:49:47 <DaveO> trackbot, status
21:50:46 <Stuart> action david provide example for jar to work into the formalism
21:50:46 <trackbot> Created ACTION-182 - Provide example for jar to work into the formalism [on David Orchard - due 2008-10-02].
21:51:25 <Stuart> action david incorporate formalism into versioning compatibility strategies
21:51:26 <trackbot> Created ACTION-183 - Incorporate formalism into versioning compatibility strategies [on David Orchard - due 2008-10-02].
22:29:25 <jar> http://images.google.com/images?hl=en&q=green+heron&btnG=Search+Images&gbv=2