See also: IRC log
<Yves> trackbot, start telcon
<trackbot> Date: 06 January 2011
<scribe> scribenick: Ashok
<scribe> scribe: Ashok
Noah: We will have a call next week. Henry can you scribe?
<ht> yes, I can scribe
<noah> http://www.w3.org/2001/tag/2010/12/16-minutes
Minutes are approved!
Noah: We have a f2f in about a month
... outgoing and incoming members are welcome to attend.
Yves: Regrets for the f2f
<Yves> I will try to participate remotely
Noah: There is a new HashInURI document. We will discuss next week. Please review.
Noah: We discussed briefly last week ... there are some action items
Dan: Tim was there at the workshop
... perhaps he has comments also
Tim: There was a range of people there ...
<Larry> It sounds good to "respect people's wishes" if we believed people understood what their wishes were, and they could be expressed reasonably
Tim: Dan: We may need a W3C focus ... maybe a get together
Noah: Difference between expectations and contents
<DKA> action-507?
<trackbot> ACTION-507 -- Daniel Appelquist to with Noah to suggest next steps for TAG on privacy -- due 2011-01-03 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/507
<Larry> Tim mentioned something about detecting someone's TCP/IP stack by observing the timing of their packets
Noah: We have action 507 which is to suggest next steps about privacy
<noah> NM: re ACTION-507, next steps for TAG, what should we do?
Dan: Minimization is important .... but it is a micro issue
<Larry> Tim said something about whether trying to solve the problem at the application layer by cutting off identifying information doesn't address the problem
DanA: Minimization is a building block but does not solve user privacy
<noah> DanA: One bit of my answer on 507 is the minimization stuff, but that's a pretty narrow slice of the privacy pie
<Larry> The whole fingerprinting issue, I think, is key
DanA: fingerprinting issue is important ... should be discussed in context of new initiative in W3C about privacy
<Zakim> Larry, you wanted to discuss whether TAG could summarize a W3C view of "what is Privacy" and "why is it hard?" to start with
Larry: Workshop focused on solutions ... there may be a initiative but could we summarize "what is Privacy" and "why is it hard?"
... this may be something the TAG should do
<Larry> Sometimes when there's a hard problem, just framing the problem can be valuable
Dan: Valuable to write up what we think the issues are
<Larry> Perhaps we could have an opinion about which things are in scope for W3C and which aren't?
<Larry> We're not going to attack packet timing, are we?
<Yves> We definitely need to check with tlr
Ashok: Also check with Philippe.
Noah: We should try and define the issues related to privacy
<noah> Action items from the workshop: http://lists.w3.org/Archives/Public/www-tag/2010Dec/att-0061/ActionItems_Workshop.pdf
Noah: If you go to Slide 3 you will see IETF actions ... slide 4 is W3C actions.
<noah> IETF Actions
<noah> • Create privacy directorate
<noah> • Investigate possible research work in privacy (IRTF)
<noah> • Explore what the IETF can learn from Tor (and vice
<noah> versa)
<noah> • Support for continuing “Privacy Considerations” work
<noah> – Apply it to some IETF protocols
<noah> – Covers HTTP/non-HTTP-based Protocols
<noah> • Fingerprinting Considerations for IETF protocols (TCP,
<noah> HTTP, SIP, etc.)
<noah> W3C Actions
<noah> • Formation of W3C Privacy Interest Group
<noah> • Fingerprinting of W3C protocols
<noah> – How to help
<noah> • API Minimalization
<noah> • Referrer header & privacy
<noah> • Privacy Considerations for Non-Browser-based
<noah> Protocols
<noah> • Usability:
<noah> – Whitepapers &BCPs (?)
<noah> – Usability Considerations in W3C specifications
Dan: There was heavy IETF participation ... they wanted privacy considerations and privacy review for each spec
... Similar to security review.
<noah> Following on Larry's thought, if you require a "privacy considerations" section, then it needs to be at least somewhat clear what's in scope under the term "privacy"
Dan: Discussion about Do Not Track mechanism ... this is important.
Yves: Points out problem with jurisdictions
Dan: Our privacy lawyer said that the EU would be looking closely at the Do Not Track and would probably follow the US lead
... The Canadian person said the same thing
<Yves> http://donottrack.us/
Dan: The Berkeley folks recommend a Do Not Track header and this had some traction
Noah discusses use of Google Analytics on his blog
<jar> donottrack.us seems sort of short on analysis and detail. Would be nice to know more
Larry: Why don't we discuss the action items?
Noah: First is to start a Privacy IG
<noah> AM: There is currently a Policy Languages IG
<noah> AM: Ends next month. That may turn into a Privacy IG
<noah> NM: Scope will change?
<noah> AM: Yes, refocus on privacy.
<noah> NM: Talk to whoever is heading the group?
<noah> AM: Talk to Rigo.
<noah> DKA: I think we need to involve Tomas
<Zakim> ht, you wanted to hesitate
HT: Do we have guidance on what the charter should be
... need guidance on the scoping of the effort
Larry: Is this an area that the TAG should actively participate
Noah: Do we have the requisite skills?
... I would have others in W3C lead the charge and the TAG track and look at suggested direction such as the DoNotTrack header
Noah reads action list above
<noah> close ACTION-506
<trackbot> ACTION-506 Noah to bring proposed W3C Actions on Privacy before the TAG - TLR to report back to IETF closed
<Larry> action-502?
<trackbot> ACTION-502 -- Jonathan Rees to report back on discussions with Ben Adida regarding fragid semantics for RDFa -- due 2010-11-29 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/502
Jar: Discusses RDFa fragment id and says this is a glitch in follow-your-nose-story
... Ben Adida says nothing is broken so nothing needs to be done
Tim: Is this an issue for Facebook?
Jar: Media types have to say what happens to RDFa
<Larry> Sometimes the thing you can do is just document the problem, even if you don't fix it
Jar: We should open an issue about this
<Larry> fixing MIME type registrations is in draft-masinter-mime-web document....
Tim: Mime types will catch up with rest of this ... If people are consistent there is no damage
<Larry> suggest the RDFa document could identify the problem, even if it doesn't fix it?
<jar> tbl: Danger - foo#a might be used as *both* an element id and as a non-element id
<Larry> +q to suggest (a) review of mime-web on mime type registration to identify problem and direction, and (b) to suggest amending RDFa document to at least identify issue
Jar: Who is going to the work?
... My docket is full
... I could draft something but cannot engage with a WG
... Ben and the editors have talked about this and they think this is not a problem
<jar> ... or if it is a problem, then it's not their problem.
<Larry> If there are known problems with a technology, even if it is someone else's problem, it should be reasonable to note the problem anyway
<Zakim> Larry, you wanted to suggest (a) review of mime-web on mime type registration to identify problem and direction, and (b) to suggest amending RDFa document to at least identify
<jar> Larry is asking me to check the mime type draft to see if this fragid issue is covered adequately
Larry: The Mime doc I'm working on does address mime type registration and we shoud review ... see above
... We can tell the editors that other people think this is a problem.
... burden should be on them
jar: I can draft something
larry: You can submit individually
jar: Are we asking them for words in their doc or for them to interact with HTML WG and 3032bis
... I think they are revising RDFa.
<Larry> I think the first step is to document what the problem is, or at least what some people think is the problem
<Larry> and that needs to be noted... Getting other people to change their spec is harder, first thing is getting consensus around at least the description of the problem
<noah> close ACTION-502
<trackbot> ACTION-502 Report back on discussions with Ben Adida regarding fragid semantics for RDFa closed
<jar> action jar to communicate with RDFa WG regarding documenting the fragid / media type issue
<trackbot> Created ACTION-509 - Communicate with RDFa WG regarding documenting the fragid / media type issue [on Jonathan Rees - due 2011-01-13].
Noah: There was a note describing the concern ... the HTML5 spec has a section on microdata
<noah> http://dev.w3.org/html5/md/#rdf
Noah: it says how microdata can be converted to RDF. This is fine if microdata is URIs. However, in some cases microdata is not URIs but just "terms"
<noah> Examples: http://dev.w3.org/html5/md/#examples
<timbl> http://www.w3.org/1999/xhtml/microdata#http://microformats.org/profile/hcard%23:
<noah> <http://example> rdf:type <http://microformats.org/profile/hcard> ;
<noah> <http://www.w3.org/1999/xhtml/microdata#http://microformats.org/profile/hcard%23:fn> "Princeton" .
First example shows full URI
Second example mints a URI ...
<noah> TBL: Seems to be an attempt to use http uris (so far so good) with an effort to put fundamental control with HTML WG, then also the microdata folks, then (...didn't catch the rest...)
<noah> TBL: Might make a bit more sense if the 2nd URI were % encoded.
<noah> TBL: Seems to let W3C publish schemas for stuff that comes from microdata folks.
<noah> TBL: Alternative is to just ask microdata folks to publish schemas directly, or that failing, put some on the side ourselves.
HT: Is this a serious proposal?
... we need someone who cares about RDF to confirm that this is serious
Larry: This is a problem with namespaces in RDF
<ht> The alternative to prefixes is full URIs throughout
<ht> Where is HTML5 on entity declaration -- not available to users, right?
Noah: So, this would require prefixes in HTML ... may be a tough battle to fight for this case
... HTML5 folks would consider this a corner case
<ht> I think Larry's point is actually relevant input into HTML Issue-41 (decentralized extensibility)
Larry: There is a significant community that does not see metadata as useful
HT: If HTML5 folks adopt a prefix binding that would simplify this part of their spec also
Noah: Is there serious proposal along these lines for issue 41?
... I don't think so.
HT: There is a mechanism for prefixing but I think it is only for attributes
<noah> NM: I thought that the only options currently open for their issue-41 were do nothing, and trigger on well known root elements (a la <svg>)
<ht> "We thus require that a prefix always map to the same namespace, and that this mapping be registered."
Tim: We should push back
Noah: Can someone draft a note that we could discuss
<noah> Actually, what I said was: can we get sufficiently close to agreement on what the TAG's key messages would be that we could ask someone to draft those points.
<noah> TBL: Normally, the person who has ownership of the URI should be the same as the one in a position to publish and maintain the ontology
Tim: The way that RDF works is that someone who creates a terminology publishes an ontology about it
<ht> Wrt the extensibility proposal (http://www.w3.org/html/wg/wiki/ChangeProposals/extensionslikesvg) it _does_ appear that xmlns:xxx=... is allowed
jar: I don't think anyone will listen unless there is an alternative ... "we don't like this" will not do much
... ask why URI has to have that form
... they may have reasons why they do it that way
<jar> still trying to understand step 6... I don't understand where 'type' comes from...
<jar> If item has an item type and that item type is an absolute URL, let type be that item type.
<jar> ahh.... meaning of attribute names is scoped to item types... so what is an item type...
<jar> so the question is, what problem is this unpleasant solution attempting to address? and is there a better alternative?
<noah> ACTION: Tim to write a note conveying the TAG's concerns re: the microdata -> RDF URI mappings in the HTML5 microdata draft Due: 2011-01-20 [recorded in http://www.w3.org/2001/tag/2011/01/06-minutes#action01]
<trackbot> Created ACTION-510 - Write a note conveying the TAG's concerns re: the microdata -> RDF URI mappings in the HTML5 microdata draft Due: 2011-01-20 [on Tim Berners-Lee - due 2011-01-13].
<jar> the URI apparently needs to combine the type URI and the attribute name, which might have a : in it
<jar> wondering what examples of type URIs are - can the property URI be built with the type URI as a prefix?