W3C home > Mailing lists > Public > www-tag@w3.org > May 2008

Draft minutes from 20 May 2008 f2f

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 28 May 2008 11:57:30 -0400
To: www-tag@w3.org
Message-ID: <m2ej7mwhed.fsf@nwalsh.com>
See http://www.w3.org/2001/tag/2008/05/20-minutes


                                   - DRAFT -

                      TAG face-to-face day 2, Bristol, GB

20 May 2008


   See also: IRC log[3]


           Tim, Jonathan, Dan, Norm, Henry, Stuart, Ashok, Dave, Noah



           Dan, Norm


     * Topics
         1. passwordsInTheClear-52
         2. namespaceDocument-8
         3. UrnsAndRegistries-50
         4. AWWSW and httpRedirections-57
         5. Self Describing Web
     * Summary of Action Items


   <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

   <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

   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,
   ... W3C security spec maintenance WG

   <Ashok> OASIS WS-SX


   <scribe> ACTION: David finish refs etc on passwords in the clear finding
   [recorded in http://www.w3.org/2008/05/20-tagmem-irc[5]]

   <trackbot-ng> Created ACTION-150 - Finish refs etc on passwords in the
   clear finding [on David Orchard - due 2008-05-27].


   <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

   <scribe> ACTION: henry announce namespaceDocument-8 finding on
   tag-announce etc. [recorded in http://www.w3.org/2008/05/20-tagmem-irc[6]]

   <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

   <scribe> ACTION: Jonathan review overlap between the HCLSI URI note and
   HT's w.r.t. contribution to TAG finding on UrnsAndRegistries [recorded in

   <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[9]

   [[[ Scribe: Is CGI691 Ashok? ]]]

   <timbl> maybe

   <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

   TBL: why didn't we ship that finding?

   <Stuart> see
   table 5 line 351.

   HT: because we thought it only worked for people who already agreed with

   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

   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[13] )

   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

   <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



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


   <scribe> Chair: Stuart

  AWWSW and httpRedirections-57

   <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[15], getting changes to either
   as needed. -- due 2008-03-06 -- OPEN

   <trackbot-ng> http://www.w3.org/2001/tag/group/track/actions/116[16]

   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[17],access

   JR: questions about pure mechanics, "the string that was in the
   ... 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[18] )

   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[19] )

   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

   <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[20] )

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

   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[22] doesn't cite the main FRBR

   <DanC_lap> aha... http://www.w3.org/2006/04/irw65/urisym#iflafrbr[23]

   <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[24]

   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[25] 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[26] )

   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

   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[27]

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

   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:

   <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

   <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

   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
   ... 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[30]#", and the value
   MUST be present in the link relation registry. is a bug to the relevant
   bug sink fro
   [recorded in http://www.w3.org/2008/05/20-tagmem-irc[32]]

   <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[33]#\", 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[34] [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

   <DanC_lap> issues in

   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

   <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

   <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

   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

   <ht> Proposal5: The TAG endorses
   http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt[40] 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

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

  Self Describing Web

   NM: Previously, I had prepared a draft for Vancouver. I got a mix of
   ... 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
   ... 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

   <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

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


   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

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

   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/[47]" />

   <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)[48]

   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

   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

   <Zakim> DanC_lap, you wanted to note HTML 5 editor doesn't consider GRDDL
   nor RDF relevant to design of HTML 5

   DanC: The HTML 5 editor doesn't consider GRDDL nor RDF relevant to the
   design of HTML 5. HTML5 has no @profile.


   <DanC_lap> Ian Hickson's rationale for not including profile, in full,
   seem to only be in the whatwg archive

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

   DanC: I kind of like the profile story

   TimBL: But there are lots of reasons why the RDFa folks don't want to do
   ... 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
   ... 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[53] )

   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[54]
   , 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

Summary of Action Items

   [NEW] 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#[55]", and the value
   MUST be present in the link relation registry. is a bug to the relevant
   bug sink fro
   [recorded in http://www.w3.org/2008/05/20-tagmem-irc[57]]
   [NEW] ACTION: David finish refs etc on passwords in the clear finding
   [recorded in http://www.w3.org/2008/05/20-tagmem-irc[58]]
   [NEW] ACTION: henry announce namespaceDocument-8 finding on tag-announce
   etc. [recorded in http://www.w3.org/2008/05/20-tagmem-irc[59]]
   [NEW] ACTION: Jonathan review overlap between the HCLSI URI note and HT's
   w.r.t. contribution to TAG finding on UrnsAndRegistries [recorded in
   [NEW] ACTION: jonathan to reply publicly to Phil with respect to our
   decision on Link: [recorded in
   [NEW] ACTION: Norman to review The Self-Describing Web, either the 12 May
   draft or the draft that comes out of this meeting [recorded in
   [NEW] ACTION: Stuart to review The Self-Describing Web, either the 12 May
   draft or the draft that comes out of this meeting [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/2001/tag/2008/05/19-agenda
   [3] http://www.w3.org/2008/05/20-tagmem-irc
   [5] http://www.w3.org/2008/05/20-tagmem-irc
   [6] http://www.w3.org/2008/05/20-tagmem-irc
   [7] http://www.w3.org/2008/05/20-tagmem-irc
   [9] http://openid.net/specs/openid-authentication-2_0.html
   [11] http://openid.net/specs/openid-authentication-2_0.html#anchor34
   [13] http://openid.net/pipermail/general/2006-November/000586.html
   [14] http://www.xdi.org/docref/legal/egs-dispute-resolution-rules.html
   [15] http://esw.w3.org/topic/AwwswDboothsRules
   [16] http://www.w3.org/2001/tag/group/track/actions/116
   [17] http://www.w3.org/2008/05/21-jar-tbl.html
   [18] http://www.w3.org/2000/Talks/www9-larch/all.htm
   [19] http://www.w3.org/2001/tag/fdesc54/slides
   [20] http://www.w3.org/2006/04/irw65/urisym
   [21] http://www.w3.org/2006/04/irw65/urisym#frbr
   [22] http://vocab.org/frbr/core
   [23] http://www.w3.org/2006/04/irw65/urisym#iflafrbr
   [24] http://www.w3.org/2008/05/21-jar-tbl.html
   [25] http://www.w3.org/2008/05/21-jar-tbl.html
   [26] http://www.w3.org/2006/04/irw65/urisym
   [27] http://www.w3.org/2006/gen.ont
   [30] http://www.iana.org/assignments/link-relations.html
   [31] http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt
   [32] http://www.w3.org/2008/05/20-tagmem-irc
   [33] http://www.iana.org/assignments/link-relations.html
   [34] http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt
   [35] http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt
   [36] http://sw.neurocommons.org/2008/uniform-access.html
   [37] http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt
   [38] http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt
   [39] http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt
   [40] http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt
   [41] http://www.w3.org/2008/05/20-tagmem-irc
   [42] http://www.w3.org/2008/05/20-tagmem-irc
   [43] http://www.w3.org/2008/05/20-tagmem-irc
   [44] http://lists.w3.org/Archives/Public/www-tag/2008May/att-0070/00-part
   [47] http://www.formsPlayer.com/
   [48] http://www.w3.org/TR/rdfa-syntax/#docconf)
   [50] http://lists.w3.org/Archives/Public/public-html/2008May/0102.html
   [51] http://lists.w3.org/Archives/Public/public-html/2007Jul/0571.html
   [53] http://esw.w3.org/topic/TPAC2007Session6
   [54] http://www.w3.org/DesignIssues/diagrams/arch/follow.graffle
   [55] http://www.iana.org/assignments/link-relations.html#
   [56] http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt
   [57] http://www.w3.org/2008/05/20-tagmem-irc
   [58] http://www.w3.org/2008/05/20-tagmem-irc
   [59] http://www.w3.org/2008/05/20-tagmem-irc
   [60] http://www.w3.org/2008/05/20-tagmem-irc
   [61] http://www.w3.org/2008/05/20-tagmem-irc
   [62] http://www.w3.org/2008/05/20-tagmem-irc
   [63] http://www.w3.org/2008/05/20-tagmem-irc
   [64] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [65] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[64] version 1.133 (CVS
    $Date: 2008/05/28 15:54:17 $

Received on Wednesday, 28 May 2008 15:58:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:57 GMT