- 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
W3C[1]
- DRAFT -
TAG face-to-face day 2, Bristol, GB
20 May 2008
Agenda[2]
See also: IRC log[3]
Attendees
Present
Tim, Jonathan, Dan, Norm, Henry, Stuart, Ashok, Dave, Noah
Regrets
Chair
Stuart
Scribe
Dan, Norm
Contents
* 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
passwordsInTheClear-52
-> 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[5]]
<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
namespaceDocument-8
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[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?)
UrnsAndRegistries-50
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[7]]
<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
http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.pdf[10]
<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[11]
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[12]
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[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
http://www.xdi.org/docref/legal/egs-dispute-resolution-rules.html[14]
<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
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
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[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
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[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
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[21]
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
work
<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
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[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
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[30]#", 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[31]
[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
http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt[35]
<DanC_lap> issues in
http://sw.neurocommons.org/2008/uniform-access.html[36]
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[37]
<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[38]
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[39]
<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
http://www.w3.org/2008/05/20-tagmem-irc[41]]
<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
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[42]]
<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[43]]
<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[44]
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/[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
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[50]
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[51]
<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[52]
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[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
http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt[56]
[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
http://www.w3.org/2008/05/20-tagmem-irc[60]]
[NEW] 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[61]]
[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
http://www.w3.org/2008/05/20-tagmem-irc[62]]
[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
http://www.w3.org/2008/05/20-tagmem-irc[63]]
[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
[10]
http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.pdf
[11] http://openid.net/specs/openid-authentication-2_0.html#anchor34
[12]
http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.pdf
[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
[52]
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-May/014692.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
log[65])
$Date: 2008/05/28 15:54:17 $
Received on Wednesday, 28 May 2008 15:58:18 UTC