See also: IRC log
<scribe> scribe: Dan
-> http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20080501 Passwords in the Clear May 1 2008
discussion of skw's comments on "The Digest method is subject to dictionary attacks, and must not be used except in circumstances where passwords are known to be of sufficient length and complexity to thwart such attacks."
SKW: I prefer to replace the imperative "must not" with factual phrasing
DO: hmm... ok
<noah> The sophistication and power of dictionary-based attacks continues to increase such that longer and complex passwords are increasingly vulnerable to attack.
NM suggests replacement for "The sophistication and power of dictionary-based attacks continues to increase such that longer and complex passwords are vulnerable to attacks, not just short passwords using common terms."
<noah> Short passwords or those using common words should not be used with digest authentication. Indeed, The sophistication and power of dictionary-based attacks continues to increase such that longer and more complex passwords are increasingly vulnerable to attack.
DO commits a 20 May revision...
DO: so on 2.1.1... are we done?
TBL: clarify "dictionary attack" as "offline dictionary attack"?
DO: the fact that it's subject to dictionary attack has to do with the presence of nonces in the protocol.
TBL: there are online dictionary attacks where each attempt involves communication with the server and offline attacks where attempts don't involve communication with the server
SKW: just add "offline"?
TBL: well... is that enough to explain it to our readership?
<timbl> add ,because a single session can be recrded and attacked offline,
<timbl> add ,because a single session can be recorded and attacked offline,
<timbl> in place of '
<timbl> in place of the comma after "disctionary attack"
<dorchard> The Digest method is subject to dictionary attacks because a single session can be recorded and attacked offline. It is particularly vulnerable in circumstances where passwords are known to be of insufficient length and complexity to thwart such attacks.
<timbl> dictionary dictionary dictionary dictionary dictionary
<timbl> +1
modulo "it", seems good to several
<dorchard> particularly vulnerable in circumstances where passwords are known to be of insufficient length and complexity to thwart such attacks.
<dorchard> particularly vulnerable in circumstances where passwords are known to be of insufficient length and complexity to thwart such attacks.
<dorchard> The Digest method is subject to dictionary attacks because a single session can be recorded and attacked offline. The Digest method is particularly vulnerable in circumstances where passwords are known to be of insufficient length and complexity to thwart such attacks.
poll shows that's ok
DO: let's look at section 1
various editorial comments
DO: on to section 2... boxed notes...
... hmm... "A server SHOULD NOT" vs "A client browser MUST NOT ..."
SKW: how does W3C's site work?
DC: basic auth. passwords in the clear. [we've tried many times to get rid of them, but we get stuck somewhere in deployment]
TBL: have we explained how to do without passwords in the clear?
DO: we talk about digest and SSL/TLS
NM: so the security context WG is saying "never do basic without ssl"... are we going that far?
DO: this finding is about "securely ..."
... as the security context WG has said, when sites like w3.org use passwords in the clear, not only is w3.org at risk, but users are trained to use passwords in the clear
TBL: how about a distinctive UI when a browser prompts for passwords that are going to be transmitted in the clear?
DO: I've seen user interfaces for password strength
NM: does it help that much if one site goes to SSL? if I've used that password elsewhere, I'm still in trouble.
SKW: naive users don't really understand these subtleties
NDW: our audience is not end-users but site developers and perhaps browser/client developers. we can make a strong statement, and perhaps they'll improve things. how they improve things is beyond our scope
DC: well...
TBL: let's target the finding and give clear advice
DO: see "Automatic Protection by User agent" which is clearly about what browsers/ajax apps...
TBL: how many sites use basic auth anyway? don't most of them use forms+cookies? are we OK with cookies?
DC: cookies are pretty much passwords to me. they're session keys
DO: no, let's leave cookies aside; this finding is about passwords
SKW: are cookies discussed in the current draft?
... "temporary storage in cookes" is in the intro
DC: regarding w3.org... if the TAG resolves that cleartext passwords MUST NOT be used, as team contact, I'll be obliged to try deploy this on w3.org; we've tried a number of times in the past and failed due to lack of software support for digest etc.
SKW: how about SSL?
DC: I don't recall how far we tried SSL; that would probably be the thing to try this time
AM: this finding advises users not to use sites that do passwords in the clear; how can users tell?
DO: there are UI clues in browsers
... given forms and javascript and such, browsers can't exhaustively determine
SKW: time draws near...
DO: the one critical issue I see is the inconsistency between SHOULD NOT and MUST NOT
... let's make them both MUST NOT
SKW: I'd prefer to just enumerate the risks and leave out the imperatives
<dorchard> There are no scenarios where it is secure to transmit passwords in the clear. Every scenario that involves possibly transmitting passwords in the clear can be redesigned for the desired functionality without a cleartext password transmission.
DO: feel obliged to represent the position of the Secrurity WG
TBL: how about "... without risk" and MUST NOT
PROPOSED: to approve the passwordsInTheClear finding, contingent on tbl's ok, and call for review by web security context wg, [http? wg], html WG, XHTML 2 WG
... OASIS WSX TC
... W3C security spec maintenance WG
<Ashok> OASIS WS-SX
so RESOLVED.
<scribe> ACTION: David finish refs etc on passwords in the clear finding [recorded in http://www.w3.org/2008/05/20-tagmem-irc]
<trackbot-ng> Created ACTION-150 - Finish refs etc on passwords in the clear finding [on David Orchard - due 2008-05-27].
[break]
<timbl> PWITC is OK by me
<timbl> You can resolve the contingency on me
TBL: I'm interested in review by browser makers too
HT: perhaps via their AC reps?
DO: not RoR devs?
TBL: sure... this is a heads up, not a round-trip, is it?
DO: this is a round-trip to many of these groups
TBL: OK, let's just notify the browser makers
SKW: we're resolved congingent on HT, NDW, and myself; the contingency has resolved.
<scribe> ACTION: henry announce namespaceDocument-8 finding on tag-announce etc. [recorded in http://www.w3.org/2008/05/20-tagmem-irc]
<trackbot-ng> Created ACTION-151 - Announce namespaceDocument-8 finding on tag-announce etc. [on Henry S. Thompson - due 2008-05-27].
JAR: has anyone implemented it?
HT: no, though any RDDL 1.0 document has the relevant info... did one of us produce a stylesheet for that?
(hmm... who's going to to update the RDDL namespace doc?)
HT: work on this was preempted by work on ARIA etc.
JAR: fwiw, Alan R. and I have been working on a document with overlapping scope
<scribe> ACTION: Jonathan review overlap between the HCLSI URI note and HT's w.r.t. contribution to TAG finding on UrnsAndRegistries [recorded in http://www.w3.org/2008/05/20-tagmem-irc]
<trackbot-ng> Created ACTION-152 - Review overlap between the HCLSI URI note and HT's w.r.t. contribution to TAG finding on UrnsAndRegistries [on Jonathan Rees - due 2008-05-27].
SKW: there was an OASIS last call on XRIs... closes 30 May
AM: remind me what our earlier comments are?
HT: [summarizes]
www-tag/2008Feb/0009.html is projected
NM: what's the status of XRIs? how does that relate to OpenID?
HT: OpenID has a forward reference to a moving target XRI spec. [?]
TBL: that's a bug [re the use of conneg in HTTP as discussed in 2008Feb/0104 ]
-> http://lists.w3.org/Archives/Public/www-tag/2008Feb/0104 XRI TC response to W3C TAG Comments on XRI Resolution 2.0
<dorchard> I see in OpenID the following: <Service xmlns="xri://$xrd*($v*2.0)">. I don't think this is legal is it?
<CGI691> from http://openid.net/specs/openid-authentication-2_0.html
[[[ Scribe: Is CGI691 Ashok? ]]]
<timbl> maybe http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.pdf
<timbl> Extensible Resource Identifier (XRI)
<timbl> Resolution Version 2.0
<timbl> Committee Draft 02
<timbl> 25 November 2007
<CGI691> I do see in OpenID Supports the use of XRIs as Identifiers. XRIs may be used as Identifiers for both end users and OPs, and provide automatic mapping from one or more reassignable i-names to a synonymous persistent Canonical ID that will never be reassigned
SKW: I've been asked what's the TAG's position on XRIs
<ht> DanC, see http://openid.net/specs/openid-authentication-2_0.html#anchor34
TBL: why didn't we ship that finding?
<Stuart> see http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.pdf table 5 line 351.
HT: because we thought it only worked for people who already agreed with us
DO: but in retrospect, that was a mistake: even that would have helped http: advocates in OpenID work
... I'm inclined to come back to this after doing some drafting over a break
NM: hmm... take a position on XRI-in-OpenID while we're at it?
... perhaps there's a risk that OpenID will be the vehicle that brings XRI into widespread use
DO: quite. I'm concerned about that.
(re xris vs email, I found something nearby... http://openid.net/pipermail/general/2006-November/000586.html )
SKW: we have some concerns, but what conclusions?
... testing the waters... poll: all the cases addressed by XRIs can be addressed using HTTP URIs?
many in support.
HT: well... there's a trade-off... if somebody gives up ubuquity, they can get more control
NM: there are certain clear drawbacks to a new scheme... list those... we haven't seen any motivation to overcome those disadvantages
... how about something like that?
<Service xmlns="xri://$xrd*($v*2.0)">
^ from openid2
<CGI691> I observe that XRI has now published a naming dispute resolution mechanism at http://www.xdi.org/docref/legal/egs-dispute-resolution-rules.html
<timbl> ACTION notes "It is not uncommon, in the context of academic debates over computer science and Web standards topics, to see the publication of one or more "considered harmful" essays. These essays have existed in some form for more than three decades now, and it has become obvious that their time has passed. Because "considered harmful" essays are, by their nature, so incendiary, they are counter-productive both in terms of encouraging open and intelligent deb
quite
[lunch]
<Norm> scribenick: norm
<scribe> scribe: Norm
Meeting resumes
ht: or wrw war aggw a rrgggww
General laughter at a joke that won't work in the minutes
<scribe> Chair: timbl
SW expresses some concerns about the tone of the message.
Proposed: We send the text drafted at this meeting to the internal tag list, with an action for Henry to fill in the blanks. To be mailed publicily by Tim and Stuart, co-chairs of the TAG.
<DanC_lap> no, not the internal tag list; www-tag
<DanC_lap> oh. I see.
Resolved.
<scribe> Chair: Stuart
<DanC_lap> action-116?
<trackbot-ng> ACTION-116 -- Tim Berners-Lee to align the tabulator internal vocabulary with the vocabulary in the rules http://esw.w3.org/topic/AwwswDboothsRules, getting changes to either as needed. -- due 2008-03-06 -- OPEN
<trackbot-ng> http://www.w3.org/2001/tag/group/track/actions/116
JR: We've been meeting by phone. Some sort of ontology for HTTP seems to be in the works.
... Some goals: use in the tabulator, use in next webarch, integration with bigger ontologies for interoperability,
... provenance (citations on the web), alignment of goals across several of these projects,
... more baking for the resource/information resource distinction,
... There's a question of how to manage the mailing list members.
HT: I think we should give JR control of the list.
General agreement.
JR: Some statements we'd like to be able to answer:
<timbl> http://www.w3.org/2008/05/21-jar-tbl.html,access
JR: questions about pure mechanics, "the string that was in the response..."
... What can you say about RFC 2616 about the entity?
... What do the status codes mean (specifically, 200 and 3xx)
... What does a 200 response say about the resource?
... What are the sources of descriptive information (link header, link element from HTML, 303 content location...)
... Question of coherence between representations.
... (Do English and French versions "say" the same thing?)
... Assessing the correctness of a mirror.
... I've got some links that I'll provide.
NM: I think there's been some scope creep. I thought it was going to be very narrowly focused, but there seems to be some much broader goals in some minds.
<DanC_lap> (fwiw, re caching, I presented at a WWW9 workshop in 2000, based on the 1994 caching paper by Luotonen and Altis. http://www.w3.org/2000/Talks/www9-larch/all.htm )
JR: I think it would be nice to deliver something, and the mechanics are interesting for some applications, but on the other hand, if I don't have a little more guidance of when 200 responses are acceptable, I won't have gotten much out of it.
TimBL: What scope creep?
NM: I actually said ambiguity. I thought it was going to be about mechanics, but there are bigger issues and they're all connected.
<DanC_lap> (more work, nov 2003 http://www.w3.org/2001/tag/fdesc54/slides )
HT: RFC 2616 puts you very close to httpRange-14.
JR: Semantic web kicks you even further. I think "what is an information resource" is a red herring, the question is, when can I give a 200 response.
<DanC_lap> (and I saw FRBR came up in awwsw email... "I suggest adopting w:InformationResource rdfs:subClassOf frbr:Work as a practical constraint." -- my IRW 2006 paper http://www.w3.org/2006/04/irw65/urisym )
JR outlines the contributions from different individuals:
scribe: David Booth's RDF capturing httpRange-14
... A use case presenting ambiguity between XML document IDs and an RDF person.
... Jonathan's category diagram
<DanC_lap> example: foo#xyz where foo has an XML representation with id="xyz", hence foo#xyz identifies part of an XML document; meanwhile, foo#xyz is claimed to identify a person.
scribe: Question of how FRBR ontologies line up with the other discussions in the group.
... (exploring the neighborhoods of 200's)
<DanC_lap> timbl, a frbr citation: http://www.w3.org/2006/04/irw65/urisym#frbr
JR: The information resource question comes to me because I want to know if someone gets a 200 for a journal article, can I use that for provenance, or do I have to setup a separate URI which 303's.
<DanC_lap> crud; http://vocab.org/frbr/core doesn't cite the main FRBR work
<DanC_lap> aha... http://www.w3.org/2006/04/irw65/urisym#iflafrbr
<DanC_lap> [IFLA]
<DanC_lap> K.G. Saur IFLA Study Group on the Functional Requirements for Bibliographic Records. Functional Requirements for Bibliographic Records: Final Report. UBCIM Publications-New Series. Vol. 19, Munchen: , 1998.
JR: The question of "time" comes up periodically, but we're trying to keep that out of scope.
<DanC_lap> http://www.w3.org/2008/05/21-jar-tbl.html
Some discussions and general agreement that it's sometimes necessary to model time but is very hard.
DanC: Is there light at the end of the tunnel?
JR: No.
NM: I think the elephant in the room is "what is an information resource"?
DanC: Is there a critical need?
JR: I want to know if I can return a 200 for a journal article.
DanC: "Yes"
JR: I'd like to be able to answer questions like that without questioning you and TimBL.
NM: We may all be happy with that answer, but there are others who aren't.
Some discussion of "what is an information resource"
<DanC_lap> HT raises a point of order whether that's what we're discussing; SKW suggests no, come to the AWWSW meetings to do that, which meeting participatns are satisfied with
JR: Maybe in six months we'll have a draft.
<DanC_lap> tbl, please put some stuff in http://www.w3.org/2008/05/21-jar-tbl.html a la "presented at a TAG meeting May 2008"
HT: I am often a fan of putting rat hole inducing topics to one side in the hopes it'll go away. I fear that the information resource question is not such a topic.
... The AWWSW group has to give some sort of concrete answer to the question of what does a 200 mean.
... If not in the actual ontology then good, english language prose to that effect.
<DanC_lap> (and I saw FRBR came up in awwsw email... "I suggest adopting w:InformationResource rdfs:subClassOf frbr:Work as a practical constraint." -- my IRW 2006 paper http://www.w3.org/2006/04/irw65/urisym )
More discussion ensues.
<ht> 'my' as in DanC ?
<DanC_lap> yes
<ht> 'I' also DanC?
<ht> (in "I suggest")
<DanC_lap> DanC: I suggest finding several examples to bound InformationResource above and below; e.g. frbr:Work
<DanC_lap> (yes)
TimBL: Another practical question: what can you deduce from relationships like when you get a 302 or conneg.
... Should you perceive that all these things are the same resource?
<ht> Note that I'm happy with what I believe to be the current state of the AWWSW emerging consensus that there is no class in the ontology named Resource
TimBL: So I added a new relationship, "same-work-as" so in the FRBR area I think we'll find wide resources that are the same work.
... That came up recently in running code.
<timbl_> Noah, http://www.w3.org/2006/gen.ont
Moving on to "redirections57"...
-> http://sw.neurocommons.org/2008/uniform-access.html
There's a document coming out in June; they'd like to say something about the link: header.
JR: If the TAG can't find an answer in time, or doesn't like it, what then?
... in that case, they'll move it to the non-normative section.
TimBL: Can we do a straw poll.
Pretty much a three-way split: in-favor, not-in-favor, undecided.
HT: I've stated my concern before: I don't want unsolicited metadata.
TimBL: What are the other concerns?
<scribe> Chair: TimBL
DanC: My concern is the relationships; are they managed in URIs or shortnames or...
JR: That's all resolved in the latest drafts.
NM: I have vague concerns, but they're not crisp enough to drive the group in any direction.
<DanC_lap> (right; so falling back to HTTP 1.0 doesn't address my concern about relationship names)
Stuart: Is Henry's concern one of taste or style or is it actively harmful?
HT: Consumption of bandwidth is the leading term. The second part is that I'm concerned its the thin end of a very long wedge.
... Header information needs to be very carefully considered. How many times ahve we had filesystems that say
... there's a data fork and a resource fork. We're going to distinguish between the message and what its about.
... It's never worked well.
... It makes me very happy to keep the seperable stuff as small as possible. We already have the problem that files don't tell you their media types.
... Now we're adding more important metadata that we won't get from file: URIs.
<Zakim> DanC_lap, you wanted to suggest bounding the class InformationResource above and below
Stuart: Is this a way of encoding metadata in the Link: header or a way of pointing to metadata
HT: The concern is that its the thin end of a long wedge.
Stuart: I don't want to encourage putting a hole RDF graph in the link headers.
<noah> I'm curious whether Henry is ultimately concerned about message size, or something deeper
TimBL: I like link: header *for* the bandwidth issue. Instead of having things creep into other headers, all sorts of metata can go in a server-generated virtual document.
... For people who really care about the metadata, they can follow the link. For others, it won't be clogging the bandwidth.
... I agree that the resource fork file architecture is sub-optimal. If it really were a resource fork then I'd see that as a bad thing.
... But the problem with the resource fork is you wind up with two open commands, one to open the data and oen to do both.
... The resource fork isn't a first-class file. The link: header is just a pointer to a file.
<DanC_lap> (I wonder what contemporary web mirroring tools do with mime types... if I have foo.html with content-type: image/gif and I copy it with wget, does it lose the image/gif media type? I bet it does)
TimBL: The resource fork is more like GETMETA.
HT: I think there are three classes, link:, GETMETA, or systematically manipulating the URI.
... Only the third has any possible way of being extended to file: URIs.
... But it's a lot easier to start a server running these days.
... I have some sympathy with the systematic URI manipulation.
... If the question was called, I wouldn't object.
AM: There are lots of different styles of metadata.
... Are you not happy because its one link for different kinds of metadata?
HT: Yes, I think that's what Tim's point just now was.
... This is as far as you get, no farther. Everything else has to leverage this.
... I don't know if this is good or not.
JR: You could go even further and just have a single "Resource-Description:" header.
HT: I didn't realize that there were going to be lots of link: headers.
... I want to say "no" to that on the same grounds.
DanC: If people fall back to HTTP 1.1 then they won't get those bits.
JR: It's a separate RFC so it could be applied to different versions.
Some discussion of the Atom/Link header registry
Further discussion of a small technical error about the use of .../link-relationships.html# as the base URI for Link: headers
-> http://www.mnot.net/drafts/draft-nottingham-http-link-header-01.txt
<timbl_> ACTION: dan to report Relationship values are URIs that identify the type of link. If the relationship is a relative URI, its base URI MUST be considered to be "http://www.iana.org/assignments/link-relations.html#", and the value MUST be present in the link relation registry. is a bug to the relevant bug sink fro http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt [recorded in http://www.w3.org/2008/05/20-tagmem-irc]
<trackbot-ng> Created ACTION-153 - Report Relationship values are URIs that identify the type of link. If the relationship is a relative URI, its base URI MUST be considered to be \"http://www.iana.org/assignments/link-relations.html#\", and the value MUST be present in the link relation registry. is a bug to the relevant bug sink fro http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt [on Dan Connolly - due 2008-05-27].
JR: The question isn't settled. I find Henry convincing, but then I think about the scenarios and what's to be said to Phil and I'm not so sure.
... The situation that brought this to my mind was a lot of documents that have metadata (lab reports, etc.) and where do you put it?
... That question is going to remain for me and the link: header is a convenient answer for a lot of administrators.
<Zakim> Stuart, you wanted to say that there can be more than one link; and to say that link is already regarded as being there.
Stuart: There can be multiple link: headers and they can be distinguished so that you can tell what link will give you WSDL and what one will give you POWDER, etc.
... Roy would say that the link: header has always been there, what Mark has done is ground the relationships in URI space.
Timbl: They can also be pushed into a single link header with commas.
... This seems like the sort of thing that the TAG should really put its weight behind.
... There are a whole lot of things taht would be made easier and it's a lever that would allow lots of innovation.
... What can we do to promote it??
JR: I'm reluctant without convincing the naysayers.
TimBL: No, what would we do if we wanted to.
JR: I think just a simple statement of support would be enough.
NM: Maybe the question is, are there strong naysayers on the outside.
JR: Yes there are
NM: So we need to either convince them or convince the people who will convince them.
JR: Do you want to go through the issues list?
Stuart: We're into break time.
<timbl_> Proposal2: The TAG recommends the use and standardization of the HTTP Link: header as described in http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt
<DanC_lap> issues in http://sw.neurocommons.org/2008/uniform-access.html
DanC: I think we should take 30 seconds and see if anyone has any of these issues they think is critical.
The group pauses to read the issues at the end of the uniform-access document.
<DanC_lap> #3 #
<DanC_lap> # Mechanisms that require special server configuration may not be accessible to all author/publishers; there will be an interaction with the way content is hosted and so on.
HT: I think 3 (mechanisms that require server configuration) is hugely important; I just want to emphasis that.
TimBL: I think we need to address that as a separate TAG issue. It's important, but we should try to get ISPs to provide more control.
DanC: You think this is a critical stopper for link:?
HT: I don't know. Many of the alternatives have this problem.
<Zakim> DanC_lap, you wanted to ask for a refined poll... not just "who likes link?" but "who finds Link to be a cost-effective solution to the powder use case? grddl? mobile bp?
DanC: If you fix the bug with the hash, then the URI relationships become information resources.
TimBL: So we should note that IANA will have to run a 303.
... But that will be useful for a lot of reasons.
TimBL highlights proposal2 above.
JR: it has to be strongly qualified
DanC: Doesn't the draft enumerate the qualifications?
... I'd like to see it used for bibliographic metadata for immutable files, POWDER, etc.
... We shouldn't recommend technology for technologies sake, we should name the use cases that it addresses.
HT: Is anyone actively championing alternatives?
<DanC_lap> I'm happy with Link for powder, grddl, and metadata for immutable files
JR: MGET has been implemented
TimBL: ... scribe missed the other example ...
DanC: There's PROPFIND, but that's not being recommended here.
Some discussion of the benefits of manipulating the URI, a la adding ",about" or /about/
<timbl_> Proposal3: The TAG recommends the use, for POWDER and metadata about fixed resources, and GRDDL transformation links; and standardization of the HTTP Link: header as described in http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt
<timbl_> Proposal4: The TAG recommends the use, for example for POWDER and metadata about fixed resources, and GRDDL transformation links; and standardization of the HTTP Link: header as described in http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt
Henry tries alternate wording
Dave likes it better
<timbl_> Proposal4a: The TAG recommends the use, for example for POWDER and metadata about fixed resources, and GRDDL transformation links; and further standardization of the HTTP Link: header as described in http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt
<ht> Proposal5: The TAG endorses http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt and standardization of the HTTP Link: header for use cases such as POWDER and metadata about fixed resources, and GRDDL transformation links
Resolved without objection
<scribe> ACTION: jonathan to reply publicly to Phil with respect to our decision on Link: [recorded in http://www.w3.org/2008/05/20-tagmem-irc]
<trackbot-ng> Created ACTION-154 - Reply publicly to Phil with respect to our decision on Link: [on Jonathan Rees - due 2008-05-27].
TimBL: Should we run the link: header on w3.org?
<timbl_> should th w3 now run this on w3.org? ,meta and link header for the w3.org site
<timbl_> for: ACL info, conneg variants, ...
Dan and TimBL to discuss that offline.
NM: Previously, I had prepared a draft for Vancouver. I got a mix of reactions.
... I republished a draft that included a number of substantive comments from the last review.
... I believe that's all I've changed in this draft.
... Some highlights:
... I've promoted the RDFa material up to its own chapter
... I put in the picture that TimBL prepared of the web's standard retreival mechanism in an appendix, after prose introduction in the text
<timbl_> The image needs a width=100% OWTTE
NM: Added principles to motivate good practices.
... I killed a few GPNs.
<DanC_lap> (hmm... the TOC lists microformats as an example of "RDF and the Self-Describing Web"; the community seems to be divided on that... ah... the text doesn't assume consensus)
<timbl_> Noah, do you have a pointer to the original PNG?
NM: The RDFa task force has sent an informal response that we should deal with.
... That's my brain dump on what's changed. I think it's ready to ship except for some RDFa details and some editorial work on the diagram.
Stuart: Can we get explicit actions to review the draft?
<DanC_lap> (I read a previous draft pretty carefully; I'm sorta used up as a reviewer)
<scribe> ACTION: Norman to review The Self-Describing Web, either the 12 May draft or the draft that comes out of this meeting [recorded in http://www.w3.org/2008/05/20-tagmem-irc]
<trackbot-ng> Created ACTION-155 - Review The Self-Describing Web, either the 12 May draft or the draft that comes out of this meeting [on Norman Walsh - due 2008-05-27].
<scribe> ACTION: Stuart to review The Self-Describing Web, either the 12 May draft or the draft that comes out of this meeting [recorded in http://www.w3.org/2008/05/20-tagmem-irc]
<trackbot-ng> Created ACTION-156 - Review The Self-Describing Web, either the 12 May draft or the draft that comes out of this meeting [on Stuart Williams - due 2008-05-27].
The group reads section 5.1 Using RDFa to produce self-describing HTML
NM: One of the RDFa TF comments is that RDFa only applies to XHTML. So I plan to fix that by changing all the references here to HTML.
<noah> http://lists.w3.org/Archives/Public/www-tag/2008May/att-0070/00-part
DanC: I think the sentence that begins "Even though..." is wrong
NM: I meant that historically, if you were developing an RDF app, you didn't need to read HTML and now you do.
TimBL: This is an example of a design question. The fragment of HTML isn't self-describing until one of two things happens:
... 1. Revise the media type so that it references RDF
... 2. Assume that GRDDL is part of the core and add a GRDDL transformation
NM: Ok, what I'm hearing is that this sentence should be deleted or restated to address Dan's concern.
... What I'd like to do is go through these two points a little bit methodically to make sure that I understand their concern and the relevant background.
... Come out of today with a story of what they could have done, what they did, and then go back and revisit the first sentence.
... So, "The last paragraph reads in part "For this example document to be self-describing, the pertinent media type and the specifications on which it depends must provide for the use of RDFa in XHTML; at the time of this writing, they do not.""
"The XHTML 2 Working Group disagrees with this statement"
Some discussion of with what they are disagreeing.
General agreement: You can't have action at a distance. The assertion that you're a member of the family isn't enough, the *actual mime type* has to point explicitly to the members of its family.
NM: There are three markers you can use to say that this is not any old HTML.
DanC: Ok, so tell the follow-your-nose story with one of these.
NM: One of the ways you can go forward is with a DTD
TimBL: Take out the DTD.
DanC: You can't, because that's part of the spec.
TimBL: The DTD is required?
NM: It's a SHOULD
-> http://www.w3.org/MarkUp/2008/ED-rdfa-syntax-20080519/#docconf
-> http://www.w3.org/TR/rdfa-syntax/#docconf
Some discussion of whether or not they have an example without a document type declaration.
DanC: If you're going to tell the follow-your-nose story with DTDs, good luck getting it past me and Tim, but otherwise you should remove it.
JR: Why do you so badly need to know there's RDFa in it?
DanC: You need the follow your nose story so that you can license the assertions in the document.
NM: Let me see if I can summarize: the relevant base spec does refer to the profile attribute, therefore we can tell the follow-your-nose story with that.
... DTDs do various things, but they aren't part of that story.
... The @version attribute recommended in the new editor's draft isn't part of the follow your nose story either.
... There are two possible paths: they could revise their spec, but let's assume they won't.
... Section 4.1 of the latest RDFa draft specifies that there are three mechanisms to indicate that a document is RDFa enhanced.
... Of these, only one, the profile attribute, is useful to make the document self describing.
<timbl_> I note that <title>My home-page</title>
<timbl_> <meta property="dc:creator" content="Mark Birbeck" />
<timbl_> <link rel="foaf:workplaceHomepage" href="http://www.formsPlayer.com/" />
<timbl_> is a FOAF error. The foaf:workplaceHomepage property I think links a person and a home page not a home page and a home page. no?
<timbl_> ------
NM: because the @profile is specifically referenced as an extension mechanism in the core specs.
... the others aren't self describing.
<timbl_> (above bug was in http://www.w3.org/TR/rdfa-syntax/#docconf)
DanC: I don't think that's a helpful way to tell the story.
Stuart: There's more than one follow-your-nose story. Perhaps we're getting confused.
NM: I thought TimBL offered a third choice that they don't mention, GRDDL.
Stuart draws a diagram
application/xhtml+xml -> RFFC 3236 -> HTML M12N -> http://www.w3.org/1999/xhtml -> RDFa specification
HT: That namespace document doesn't actually refer to the RDFa specification yet, but it does say it might.
Some discussion about whether or not the MIME type specification actually gives you enough information to follow your nose.
It's not as crisp as one might like, but arguably works.
RFC 3236 says "With respect to XHTML Modularization [XHTMLMOD] and the existence
of XHTML based languages (referred to as XHTML family members)
that are not XHTML 1.0 conformant languages, it is possible that
'application/xhtml+xml' may be used to describe some of these
documents. However, it should suffice for now for the purposes of
interoperability that user agents accepting
'application/xhtml+xml' content use the user agent conformance
rules in [XHTML1].
"
From which we get from the MIME type to the namespace document.
By way of M12N.
NM: I'll revisit the sentence "Even though this..." in 5.1 of Self Describing Web and redraft.
... And pull the DOCTYPE
Stuart: So you're going to redraft?
NM: As I said, I think it's pretty good except for the RDFa stuff and now I can fix that.
Some discussion of how to respond to the RDFa email message.
<Zakim> timbl_, you wanted to sggest remove doctype and to ask what the follow your nose algo *is* here in RDFa, the section seems to duck the issue
<Zakim> DanC_lap, you wanted to note HTML 5 editor doesn't consider GRDDL nor RDF relevant to design of HTML 5 http://lists.w3.org/Archives/Public/public-html/2008May/0102.html
DanC: The HTML 5 editor doesn't consider GRDDL nor RDF relevant to the design of HTML 5. HTML5 has no @profile.
<DanC_lap> http://lists.w3.org/Archives/Public/public-html/2007Jul/0571.html
<DanC_lap> Ian Hickson's rationale for not including profile, in full, seem to only be in the whatwg archive http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-May/014692.html
DanC: I disagree with him on an architectural basis, but I can't argue with the fact that lots of authors won't use @profile.
TimBL: Leaving these things out prevents smaller communities from innovating.
... The RDF community would like a profile so that they can use HTML in the ways that they want, even though they are a minority community.
DanC: "But RDF is not relevant to real life"
TimBL: That's just not socially inappropriate.
Some discussion of how best this argument could be phrased.
Stuart: There were topics we wanted to come back to, how should we adjust our agenda for tomorrow?
<DanC_lap> I heard tim give a little bit of something new: "to ignore the overlap between the RDF and HTML communities is unacceptable"
NM: I believe that XHTML says it may sometimes be necessary to deliver it with text/html. Furthermore, lots of it is delivered that way.
... I tried to cover follow-your-nose from text/html.
DanC: You can't.
NM: So I could just leave it out, or I could say why text/html doesn't work.
DanC: I kind of like the profile story
TimBL: But there are lots of reasons why the RDFa folks don't want to do that.
... They story I think we should tell is that text/html is a poor person's XML and the implicit namespace for text/html documents is the XHTML namespace.
... The other way is to make the RDFa spec is part of the core
Scribe note: this is a third option from Tim's earlier list
<DanC_lap> (a point I noted earlier: Ian Hickson: For example, in most of about a billion pages I hit in 2005 I found that the html 4 profile attribute was used in about 1.4 million pages... which sounds like a lot, until you realize that the dc.title in the <meta> element, which you should always use with the profile attribute was used about 19 million times. So 1.4 million times we use profile ever, and 19 million times we use dc.title, just one of any number of v
<DanC_lap> alues that requires the profile attribute. So that's 10 times more times we use the extension mechanism than we use the extension declaration it wants. -- http://esw.w3.org/topic/TPAC2007Session6 )
Some more discussion of the text/html media type.
DanC: The text of the text/html media type spec probably hasn't caught up with current understanding.
NW: I think you could just leave it out.
NM: But there's a lot of XHTML that's served as text/html
NW: I still think you could just leave it out.
Some discussion of the editorial mods needed to the graphic.
<DanC_lap> (what was that address, timbl?)
<timbl_> (http://www.w3.org/DesignIssues/diagrams/arch/follow.graffle , danc)
Stuart: What was the outcome of the @profile discussion?
DanC: You're all notified and I might follow up with TimBl. I accepted that there was no action following.
Stuart: There were a few things to potentially revisit:
... XML Versioning
... Distributed extensibility
... URNs and Registries
<DanC_lap> agenda order is 15, 16, 13, 14
<DanC_lap> agenda order is 12
<DanC_lap> agenda order is 12, 15, 16, 13
Adjourned for the day
<DanC_lap> scribe editing: HT for day 1, Norm for day 2, Noah for day 3