TAG Sep 2008 -- 25 Sep 2008

25 Sep 2008

See also: IRC log


Stuart_Williams_(SKW), Dave_Orchard_(DO), Tim_Berners-Lee_(TBL), Henry_Thompson_(HT), Dan_Connolly_(DC), Ashok_Malhotra_(AM), Jonathan_Rees_(JAR), TV_Raman_(TVR), Noah_Mendelsohn_(NM)
Ashok, DanC


<scribe> Scribe: Ashok

TimbL: Noah, the GRDDL and stylesheet changed for yr document
... action-130 is almost done.

issue passwordsInTheClear-52

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


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

Thanks to the host

<DanC_lap> scribe: DanC

<DanC_lap> scribenick: DanC_lap

RESOLUTION: to thank the Kauffman foundation for the meeting venue. with applause.

XMLVersioning-41 (cont)

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)


<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)


--- break ---

<Stuart> agenda

<Stuart> drop agenda item 5

agenda order is 4, 2, 1, 3, 5

wrap up on HTML

HT: about TPAC... next telcon is probably too late to start setting up a meeting

SKW: I've heard concerns ...

DC: plan optimistically?

. ACTION: Stuart contact HTML WG chairs about TPAC possibilities

<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... ]

whiteboard photo

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].


(some technical discussion continued...)

Postscript: versioning formalism

<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].

Summary of Action Items

[NEW] 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]
[NEW] ACTION: Stuart contact HTML WG chairs about TPAC possibilities... spec modularization, etc. [recorded in http://www.w3.org/2008/09/25-tagmem-irc]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2008/10/07 18:36:06 $