See also: IRC log
<scribe> Scribe: Ashok
TimbL: Noah, the GRDDL and
stylesheet changed for yr document
... action-130 is almost done.
DaveO: Summarizes cover note
<Norm> Diff
DaveO: I think option 3 is best. We should allow digest authentication
ht: I like 2
TimbL: can we can clear text almost always bad, digest is better. All have problems
Dave: We will get push back from sec WG
Noah: Different usecases
... The word 'ok' is not ok
<timbl> I suggest discussion by suggetsion of lternate text
<timbl> Clear text passwords are a serious security risk,though sometimes are acceptable.
<Norm> The question is: do we want to write something that's about policy or pragmatics?
Stuart: We are talking abt technoligies rather than priciples
<DaveO> I think pragmatics...
<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.
<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.
<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'
<noah> Should he really warn all family members to never, ever use for that site the same password they use for banking? Yes.
<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.
Raman: We are saying MUST and SHOULD abt things we have no control over
<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.
jar: I liked the stmt that doing ... is not without risk
<Zakim> jar, you wanted to comment re 'not without risk'
jar: Function of what threats you are trying to protect against
<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 ..."
Timbl: discusses his suggested text above
<DanC_lap> hmm... "always more secure"... darn; can't think of a replacement
Dave: We could not get to consensus on the good practive notes.
TimBl: You can use my text to
wtite good practice notes.
... You can also tell stories
<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...)
<DanC_lap> (darn; looks like I didn't bookmark it.)
<timbl> (I suspect that someone has probably packaged and patented your hash-based password management system, dan! :) )
Dave: I can work this in during the break
<Zakim> ht, you wanted to endorse TV's suggested change of rhetorical approach
ht: Trying to frame things as advice is sensible. Can be couched as good practice
<Zakim> noah, you wanted to suggest Tim's approach, but with examples.
Noah: I think we shd either kill
or publish this
... Shd add some stories
<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?)
Noah: outlines some failure modes
<Stuart> ack me#
<jar> +1 to what noah is saying. purpose of document should ideally be to teach people about risks they may not have thought about
skw: one risk is users reuse
passwords. We don't say this
... We are trying to educate naive users
Dave: I can come up with some stories
skw: Weak passwords cause
poblems
... These are not sensetive. The principle is not exposing
sensetive info in the clear
TimBl: Cannot divide into 2 groups. It's a continuum
<Zakim> timbl, you wanted to suggest references
TimBl: we shd put specific references to stories, academic discussions, security papers
skw: Security context WG would be open to meeting with us
ht: Trying to shift tone to advice rather than normative statements backed up with some stories
jar: Why is this a tag issue, historically?
<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 )
TimBl: We advise people how to run servers
Dave: Some tag member felt passionately abt this
<timbl> See for example http://en.wikipedia.org/wiki/Digest_access_authentication#Disadvantages
skw: He wanted some levers to beat browser mfgs with
TimBl: We talked to security
experts. They were horrified we recommended digest
authentication
... They work at the high end
Noah: They had 'just say no' appoach. Their users were a diverse group.
TimBl: World would be safer is people just moved to digest authentication by flipping a few bits
Dave: I can fix the words as Tim suggested and add references
skw: Let's go thru the diffs
No objection to changes in 2.1.1
<DaveO> there is no standard way of
<DaveO> performing a salting/digesting mechanism? The User-agent and the server
<DaveO> will have to agree on the exact data and algorithm via some non-standard
<DaveO> out-of-band mechanism - which goes beyond the provisions of
<DaveO> HTTP Digest Auth mechanism as defined in RFC 2617.
Noah: Can we add these sentences?
<DaveO> This makes me think that if the requirement is that a user-agent MUST
<DaveO> NOT transmit a password in the clear, then the server MUST NOT store
<DaveO> cleartext passwords or the server MUST use SSL/TLS. Ultimately, that is
<DaveO> where the Web should be headed. Tricky thing to say though ;)
<Norm> I'm fine with Dave's edits.
No objections tochanges in 2.1.3
<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)
Ashok: Add references to new security technologies
DanC: yes, please
<DanC_lap> cite http://openid.net/specs/openid-authentication-1_1.html May 2006
No objection to changes in section 4
jar: I have 5 editorial changes. I will mail them to you
<DanC_lap> and cite http://oauth.net/core/1.0/ Dec 2007 "OAuth Core 1.0"
<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
<DanC_lap> ... Security Assertion Markup Language (SAML) v1.1 [OASIS 200308]
<DaveO> http://www.w3.org/2001/tag/doc/versioning-compatibility-strategies-080520-080917.html
<Ashok_> Versioning diff
DaveO: Runs thru diffs since 5/20
Section 1.2 bullet 4
CSS 2.1 was a subset of 2 with features people actually used.
<DanC_lap> (the diff is from which draft?)
Changed definitions of forwards and backwards compatible
Noah: This is a relation between 2 specs. Why are consumers in this?
jar: Its a relation between producers and consumers
Some members signal approval of text
<Zakim> raman, you wanted to remark on css bits
raman: CSS text goes away from what the document says. CSS says 'no versioning'.
This doc talks abt major/minor version numbers
DaveO: Doc does not require version identifiers
<DanC_lap> (the css vendor prefixes... moz-3d-margin sure looks more like <apple:canvas> than <canvas>. hmm.)
DaveO: Doc discusses how CSS allows extensibility -- compatible versioning strategy
ht: There are people who love CSS versioning and some hate is
DaveO: CSS has implicit contract not to introduce backwards incompatibility
Noah: That's worth talking about
<Zakim> DanC_lap, you wanted to think out loud about <apple:canvas>/<canvas> and -moz-3d-margin
Discussion abt how CSS evolves
<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...
jar: Use Wikipedia as registry
<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
<DanC_lap> TVR: well, some people are happy...
TVR: I would like some mods to CSS story
DaveO: Not got to it yet
Section 2.1.1
Includes some text abt benefits of version identifiers and some new stuff abt CSS
typo in Good Practice
remove 'excellent'
Dan: Need example of where version numbers worked
Noah: Version identifiers may be mixed blessing
TimBl: Lets tell the sories. Tell the Babble story including the TECO parts
<DanC_lap> (oops; I only meant to suggest changing the order of the paragraphs. )
<DanC_lap> (the text is acceptable to me as is, once "excellent" is struck.)
Say that CSS does not use versions and there is controversy abt this
DaveO: It now has stories
TimBl: Let's not generalize from stories
<Norm> Ring ring
skw: 'may be a side benefit' is weak. say 'a benefit'
<DaveO> A benefit of having no version identifiers is...
Dan: Would prefer CSS later.
<DaveO> rewrite the double because sentence
Noah: Editorial- rewrite sentence with 2 becauses
ht: Do the negatives come later on?
DaveO: Problem is to specify meaning of version identifiers
Noah: Do we have success stories on version identifiers?
ht: XSLT
raman: EXSLT work is good example
TimBl: Is it in wide use
Raman: Yes, it's very successful
Editorial: 'it is may be'
Noah: Could split into 3 paras
Editorial 'the which'
<DanC_lap> (Dave, I prepared more on section 5, as we discussed when putting the reading list together. Is it awkard to skip there?)
<DaveO> should specify how and where any version identifiers can occur and the meaning..
jar: one question is shd there be version ids
related question is what to do with version ids
<DaveO> you should be explicit about the version identifier strategy.
Good Practice: "Any languages intended for versioning " is misleading
<DaveO> languages intended for versioning -> languages that are intended to be versioned
<DaveO> or intended to evolve...
<DaveO> Languages should specify the meaning of any version identifiers
<timbl> In 5.2 th content of OBJECT might be a better example than the @alt attribute
<timbl> maybe not
DaveO: Let's skip to section 5
<DaveO> "good example" -> "example"
<DaveO> "this is a good example", what "this"?
<DaveO> in the xml language, add "itself"
jar: use of data: is dangerous in light of our discussion on separation of concerns
<DanC_lap> good catch, jar.
<DaveO> Change HTML not extensible to forms or tables
jar: use different example
daveo: forms or tables
raman: Ignore unrecognized element was a bad example -- ties yr hands
does not give you extensibility and forces people to use attributes because attributes are not rendered
TimBL: This was great for adding cite: and ... but was bad for adding script
<DaveO> Add a forward reference to ignore all or part...
TimBL: I liked the bit about mapping from language you don't understand to what you do understand.
<DanC_lap> ... for extensibility; unknown tags were ignored.
<DaveO> "may be encountered" add "and should be ignored"
<DanC_lap> dave, my edit (2 lines up) makes the sentence shorter.
<DanC_lap> not critical.
TimBl: Does it tell the XML story?
The rqeuirement that if you don't understand the version Id you stop made it hard to create new versions
TimBl: Story is migration to XML 1.1 failed. We ended up adding the changes to 1.o without changing the version number
c/1.o/1.0/
Fourth para after section 5
XML could have provided fallback strategy
Discussion about XML extensibility
<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,
Noah: ... all the texts that may be accepted by later versions are accepted in the first version in some way
TimBl: For example ignore ....
change 'almost infinite' to 'unbounded' to unbounded'
<DaveO> XML was not as extensible...
<DaveO> ?
<DaveO> the XML language is much less extensible than HTML.
<DaveO> is is usable to create..
<scribe> Finished discussion upto start of 5.1
<DanC_lap> scribe: DanC
<DanC_lap> scribenick: DanC_lap
RESOLUTION: to thank the Kauffman foundation for the meeting venue. with applause.
DO: made some edits just now...
DO: note updates in section 5...
NDW: hmm... XML 1.0 5ed sheds new light on that para about XML extenisibility
<timbl> (in the text!)
<timbl> change "scripts" "the <script> tag"
NDW: the edits to these 2 paras are an improvement
DC: yeah; I'm ready to move on
<timbl> change "some types of extensions" to "some types of extensions such as th <cite> and <tt> tags"
<timbl> change "some types of extensions" to "some types of extensions such as th <cite> and <tt> markup tags"
<timbl> change "almost unbounded" to "unbounded"
<timbl> delete "as attempted by xml 1.1"
<timbl> (It was not that issue which prevented xml1.1 from working)
DanC: the "Good practice" label seems wrong; these are design choices, not things we expect every design to follow, right?
DO: well, not in the 1st case in 5.1
<Zakim> DanC_lap, you wanted to suggest dropping the 1st box
tbl example: <p> <foo> hello world <i>!</></foo> </p>
(diversion into the history of HTML ...)
(ah... dave's memory is better than mine...
"HTML user agents supports a superset of the HTML 2.0 language by
reducing it to HTML 2.0: markup in the form of a start-tag or end-
tag, whose generic identifier is not declared is mapped to nothing
during tokenization."
)
-- http://ftp.ics.uci.edu/pub/ietf/html/rfc1866.txt
TVR: ...
JAR: this is exactly what Lisp did in 1962: separate read from eval
[there was an analogy to HTML 5 parse-to-dom and do-stuff-with-dom]
NM: is this it? language specifications may provide for 2 flavors of forward compatibilty: (1) clients ignore... (2) clients preserve...
DO: yes, something like that
<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.
<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.
SKW: trying to understand these rules... they're choices to adopt or not?
DO: I think so...
HST: hmm... rules with SHOULD etc... isn't the rule just "accept and discard any portion you don't recognize"
TBL: these are phrased imperatively, yes?
HST: yes...
... you could say things like "a processor is
forward-compatible-happy if it does rule-X or rule-Y"
... consider "text portions that are not in the defined set are
accepted and discarded"
... though 'defined set' is perhaps the wrong generation of
terminology
(re "rule" ... brainstorming... "design pattern" or "design choice")
<ht> or 'strategy'
+1 strategy
TBL: strategy is something can adopt or not. good idea.
(is "strategy" actually already used? this is a question of fact)
DO: it's awkward to have forward-compatibility strategies built from strategies.
<timbl> (strategy is used)
(where?)
<Stuart> fwiw: forward compat or backward compat etc are design goals for or propreties of a language.
<timbl> (... For example, many W3C languages adopt a strategy of allowing incompatible changes in Working Drafts ...)
DO: acceptable to go with "rule" and take the SHOULDs out?
DC: yes
AM: yes
<Stuart> These 'rules'/'practices' are things that can be used to accomplish compatibility goals.
TBL: or a different style.
DO: ok.
<Zakim> timbl, you wanted to point out that "accept abnd preseve" des not apply generally to arbitrary languages, only to marku.
TBL: the notion of "preserve" is explained as though it applies to all languages, but for languages like C/perl, it makes no sense. The input and output of a C compiler aren't of the same type..
DC: hmm... seems to make sense to me.
TBL: what does it mean for an
HTTP server to 'preserve' a header?
... yes, it makes sense for proxies, but what about origin
servers?
NM: logging, for example
DO: what the text says is that the HTTP language follows both the preserve rule and the ignore rule
DC: only starting to understand this concern, Tim; does a suggested change occur to you?
TBL: hmm... no... maybe ok to let it go
DO: I see that the presentation of the rules needs work.
DO: let's look at 5.3 Version Identifiers
<Stuart> re 5.3: suggest s/Two of more the popular ones follow:/Two popular models follow/
NM: is this stuff about version
identifiers only about forward compatibility
... is this stuff about version identifiers only about forward
compatibility?
DC: note section 5 is all about forward compatiblity
NM: then append "... for Forward Compatibility" in the label of 5.3, pls
(my sympathy with the "don't generalize so much from the stories" comment grows.)
DC: I read this box too quickly; now that I look again, I'm struggling to make sense
<DaveO> Need to update 5.3 to change "producer understands" to "documents that are compatible with".
<DaveO> and provide back ref
<jar> 5.3.1 Please either define "valid" or use some other term
(where, jar? ah... "A text may contain a version identifier for texts that are valid under multiple versions" )
NM: ... default model... what's that?
<jar> (thinking aloud) When a producer provides a version identifier in a text, it is asserting something about the rest of the text.
<DaveO> some mix ups around "default model" "handling model" "processing model"
<DaveO> "interpretation model"
<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
evidently not.
<jar> Then the consumer has to draw its own conclusion, according to the language family's versioning strategy.
<DaveO> default model for identifiers does not tie structure of identifiers.
<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?)
<jar> (that was continued thinking aloud)
<DaveO> need to redo 5.3.1 gpn.
<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"
<DaveO> languages should specify the meaning of the structure of identifiers wrt compatible/incompatible evolution.
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?
DO: the numbers
<Stuart> 5.3.1 3rd para begins "Then... " without an antecedent upon which the consequent depends.
DO: gpn should be something
like...
... when texts will contain the highest. --
NM: when a language specification uses the strategy that documents will be labelled with the highest version...
HT: this is just "authors write the version number they use"
NM: it's more than that...
... some of this strategy is... this is leading toward
major/minor
(darn; several seems to get it, but I couldn't follow well enough to write it down)
-Norm
--- break ---
<Stuart> agenda
<Stuart> drop agenda item 5
agenda order is 4, 2, 1, 3, 5
HT: about TPAC... next telcon is probably too late to start setting up a meeting
SKW: I've heard concerns ...
DC: plan optimistically?
<scribe> ACTION: Stuart contact HTML WG chairs about TPAC possibilities... spec modularization, etc. [recorded in http://www.w3.org/2008/09/25-tagmem-irc]
<trackbot> Created ACTION-179 - Contact HTML WG chairs about TPAC possibilities... spec modularization, etc. [on Stuart Williams - due 2008-10-02].
HT: thinking about ways to
organize the HTML 5 spec into parts... the idea of parser vs
object model ...
... 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.
... I'm more interested a split between language definition and
error correction
<DanC_> (in passing, I think the split around dom is feasible; it's the way the spec is currently organized, more or less)
discussion of agenda planning around HTML...
HT: I'll send my minor comments
individually...
... but each of the 1st 3 paras in [see minutes earlier] are
issues I think the TAG should agree whether to comment on
(tbl refers to self-describing web ... rrs action june )
TBL: [... missed... ]
HT: yes, we could do that,
but...
... neither the EXI community nor the XML community wants
generic XML processors to process EXI...
... the target is that there are separate stacks until you get
to the infoset
NM: another concern is w.r.t.
branding
... i.e. don't upset expectations that XML mostly just
works
HT: so this argues for "(a) TAG
should endorse it and (b) EXI WG should ack the kludge"
... ... "doesn't achieve byte-for-byte fidelity even for XML
docs"
<DaveO> Norm generated: http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-080912-080925-diff.html
<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 [recorded in http://www.w3.org/2008/09/25-tagmem-irc]
<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].
ADJOURN.
(some technical discussion continued...)
<timbl> Alternative language versioning formalism
<Stuart> cation jar update versioning formalism to align with terminology in versioning compatibility strategies
<Stuart> action jar update versioning formalism to align with terminology in versioning compatibility strategies
<trackbot> Created ACTION-181 - Update versioning formalism to align with terminology in versioning compatibility strategies [on Jonathan Rees - due 2008-10-02].
<Stuart> trackbot, status
<DaveO> trackbot, status
<Stuart> action david provide example for jar to work into the formalism
<trackbot> Created ACTION-182 - Provide example for jar to work into the formalism [on David Orchard - due 2008-10-02].
<Stuart> action david incorporate formalism into versioning compatibility strategies
<trackbot> Created ACTION-183 - Incorporate formalism into versioning compatibility strategies [on David Orchard - due 2008-10-02].