Draft TAG minutes from telcon of 2012-06-21

Now available at


and below as plain text.

                                   - DRAFT -

                  Technical Architecture Group Teleconference

21 Jun 2012


   See also: [3]IRC log


          Robin Berjon, Yves Lafon, Peter Linss, Ashok Malhotra, Noah
          Mendelsohn, Jeni Tennison, Henry S. Thompson, Jonathan Rees

          Tim Berners-Lee, Larry Masinter

          Noah Mendelsohn

          Noah Mendelsohn, Jeni Tennison, Henry S. Thompson


     * [4]Topics
         1. [5]Copyright and Linking: ISSUE-25 (deepLinking-25): Can
            publication of hyperlinks constitute copyright infringment?
         2. [6]Fragment Identifiers
     * [7]Summary of Action Items

   noah: we won't meet next two weeks, will meet Jul 12

   noah: we are missing minutes from 12th & 14th of F2F
   ... we'll be talking about who can carry forward work on Publishing &
   ... we'll then talk through the rest of the fragids draft
   ... anything else?

   <ht> I'm working on my minutes for 12th (Tuesday)

   Ashok: can we talk about the acct: URI scheme?

   noah: we did have some discussion at F2F
   ... if we don't get to it today, we'll try to schedule another chat
   about it

Copyright and Linking: ISSUE-25 (deepLinking-25): Can publication of
hyperlinks constitute copyright infringment?

   NM: Larry and Ashok have both expressed an interest

   NM:Goal is to decide who will pick up from Jeni...both Ashok and Larry
   have expressed interest.

   JT: We last discussed this at the F2F in France. There were some
   editorial matters. The biggest piece of work was to make sure the vocab
   and terminology was aligned with existing specs, and to reference those
   ... We also talked about how to take it forward procedurally. The
   suggestion was to set up a CG after editorial changes are done, and
   give them the document as input.
   ... On that basis, the sense was that it is quite close to being ready
   to publish.

   <jar> 0

   <darobin> +1

   <ht> 0

   ashok +1

   NM: OK, that's two. Not great, but at least we have some informed
   independent opinions.

   AM: I disagreed with some of the messages. I would like a stronger
   ... The messages in this version are very weak. I've been told by Jeni
   and Jonathan that a stronger message would represent a legal opinion,
   which we aren't in a position to give.

   <jar> no, not just aligning terminology

   JT: Responsing to Ashok. Earlier drafts had stronger messages. The
   opinion expressed from various members, I think Jonathan and Larry
   especially, was that the strong statements were not appropriate. Our
   role should be to help align terminology between technical and legal

   <Yves> strong +1

   JT: We did talk about having a separate {article, blog post, whatever}
   in which we might express stronger opinions.

   <jar> agree with "the opinion expressed" but not "our role should be"

   JT: I started on a draft of that, but got stuck. Couldn't think of what
   to say. I would support a separate document, but not here.

   <Zakim> Important for TAG, willing to work on it in 'pick a victim'

   JAR: As I said in IRC with what Larry and I were saying before, but: I
   don't think we have to limit it quite to only terminology. We can go as
   far as saying: "this is what the technology is for...this is why we're
   doing all of this". If you're doing something with legal force that is
   in conflict there will be problems. That's a fact, not a legal opinion.

   AM: I have a very specific point in my e-mail: "if you link to material
   that is illegal or seditious, you may be prosecuted...you may want to
   be careful"

   <Zakim> JeniT, you wanted to say I liked what Jonathan said in one of
   his emails


   <Ashok> Jonathan, I did read your mail

   JT: See JAR's e-mail linked above. It may be useful to have technology
   that allows people to express what is and isn't permitted.

   <jar> Maybe we can be explicit about the "chilling effects" idea

   <Zakim> noah, you wanted to express nervousness with Ashok's request

   NM: I'm more reluctant than Ashok to go as far as he wants to go.
   Talking about something seditious is a term of art in the legal
   community. I think we want to steer clear of those abstractions. I
   think we should focus on what we can talk about, around technology and
   the way the web works.

   NM: and explain how if people pass laws that conflict with use of the
   web, there will be issues to resolve. Anything that talks about what's
   legal is limited in jurisdiction. I'm even nervous about technical
   protocols that indicate permissions.

   <jar> Not just law, also judgment and contract!

   JAR: I think I disagree with NM
   ... There are some ideas that are not legal by nature
   ... e.g. 'license'

   JAR: We don't always have to shy away from them
   ... We all make judgements

   <noah> Do all jurisdictions have licenses? I would have thought the Web
   is used in areas where legal frameworks are less developed, or

   <noah> Mostly, I want to stop short of implying that the TAG knows
   anything about how license or copyright terms advertised in, say, the
   UK should be interpreted outside of the UK

   JAR: If an authority tries to impose conditions, there's a problem if
   no objective criteria exist for determining if those conditions apply
   ... So I think we can make useful contribution in such spaces, w/o
   talking specifically about the law in any particular jurisdiction

   NM: We have to be careful about not appearing to make claims across

   JAR: We can include disclaimers, but it is certainly possibly to talk
   about these things without talking about law

   <jar> You can say: If a decision requires human judgment, it can't be
   made by a computer

   AM: I want to hear what JAR thinks we can say

   YL: Discussing things associated with law and jurisdiction, you are
   moving from the technical to the political
   ... And I think expressing a political opinion is wrong for the TAG

   <jar> I am not saying we should talk about the law. We should talk
   about the purpose of the technology, and the fact that computer can't
   make judgments

   NM: So, no interest in abandoning
   ... JT suggested we proceed by coming up with a document, then setting
   up a Community Group to take it forward
   ... Originally we discussed have a document which we the TAG could use
   to get visibility from various policy-making groups

   NM: So, agreed that we should find some editors, and then handing off
   to a CG?

   [nem. con.]

   <JeniT> worth re-reading the minutes at

   NM: Ashok?

   AM: I would be happier picking this up if we can say slightly stronger
   ... I need to talk offline with JAR before being sure

   NM: OK, regretfully, we have to pend the editor decision

   <JeniT> see what Larry says too, I think he's happy with the current

   JAR: I have other things ahead of this, but if all else fails, I'll
   take it on

   NM: Not that bad yet -- AM has said he'll try to bring a proposal
   forward, whose acceptance would mean he would take on the editor job

   <jar> +1 ashok as editor for next 3 weeks

   <ht> +1

   NM: Please, AM, reach out to LM and let him know where you are going
   ... Best way to help us decide would be for AM to draft some fragments
   of text indicating the new direction

   <noah> ACTION-541?

   <trackbot> ACTION-541 -- Jeni Tennison to helped by DKA to produce
   draft on technical issues relating to copyright/linking -- due
   2012-08-01 -- OPEN

   <trackbot> [10]http://www.w3.org/2001/tag/group/track/actions/541

   <noah> close ACTION-541

   <trackbot> ACTION-541 Helped by DKA to produce draft on technical
   issues relating to copyright/linking closed

   ACtION Ashok with help from JAR to work on a plan for taking a slightly
   stronger version of the Copyright and Linking draft forward

   <trackbot> Created ACTION-727 - With help from JAR to work on a plan
   for taking a slightly stronger version of the Copyright and Linking
   draft forward [on Ashok Malhotra - due 2012-06-28].

   <noah> ACTION: Noah to find editor for copyright and linking after
   group reviews Ashok's proposals on stronger messages - Due 2012-08-12
   [recorded in

   <trackbot> Created ACTION-728 - find editor for copyright and linking
   after group reviews Ashok's proposals on stronger messages [on Noah
   Mendelsohn - due 2012-08-12].

   trackbot, action-727 due 2012-07-10

   <trackbot> ACTION-727 With help from JAR to work on a plan for taking a
   slightly stronger version of the Copyright and Linking draft forward
   due date now 2012-07-10

   <noah> ACTION-728 Due 2012-07-12

   <trackbot> ACTION-728 find editor for copyright and linking after group
   reviews Ashok's proposals on stronger messages due date now 2012-07-12

Fragment Identifiers

   JT: We got to just before section 4 in our review at the recent F2F

   <jar> N.b. the latest version at
   [12]http://www.w3.org/2001/tag/doc/mimeTypesAndFragids is not what's
   linked from the minutes

   <jar> May 28 vs. June 12

   JT: We had mostly focussed on the Best Practices, but with some need
   for clearer exposition


   HST: When we get to the right time, I'll have some things to say

   <noah> Are we in section 3 or 4?

   JT: We did agree some redrafting -- in particular wrt barenames, I will
   say something to the effect that if a suffix scheme says something
   about barenames, particular schemes should respect that

   <noah> I'm a little troubled by:

   <noah> Best Practice 8: Do Not Specify Use of Plain Name Fragment

   <noah> Structured syntax suffix registrations should not define
   processor behaviour for plain name fragment identifiers.

   HST: Ah, I hadn't remembered that -- yes, that would be good

   JT: Yes, that's the one I agreed to change

   NM: So what would the new approach be

   JT: Structured SSR should not define processor behaviour for plain name
   fragment identifiers, but if the do it should be in line with that
   basis media type -- e.g. +xml is OK, based on /xml

   NM: Why are we saying 'should not' in the first place?

   HST: Likewise

   NM: Still not sure why this says SHOULD NOT

   JT: I will revisit what we said in Nice, but my recollection was that
   plain names were special, and that they are good for referencing things
   at the level of a particular media type
   ... So that we want them to be left for individual media types
   ... Particularly if you are interpreting from multiple media types, all
   of which have said things about plainnames, then you don't have the
   freedom you need

   NM: I'd be happier with a tradeoff, so that we should the pros and cons
   ... [ two sides of the coin ]
   ... Then suffix reg. for plainnames would be an example

   <jar> "please don't conflict with what anyone else does" is an
   unfollowable request

   NM: I think it's OK to say this in a generic suffix case

   HST: I also thought it was because we recognized that it was coherent
   to not do the land grab across the board that we were happy to have
   suffix registrations say what they do. We thought it was important that
   suffix registrations say that where a barename doesn't refer per the
   suffix, then it's free to be given a referent by a "junior"

   HST: That's where I thought we ended up.

   HST: HT: I hear you say you're going to review the Nice/Sophia minutes,
   and that's enough for me.

   HST: I'm happy based on your commitment to review

   HST: I have not made progress with Chris Lilley. The IETF work on
   suffix registrations is going to be approved within the week.

   HST: I feel its reference to +xml is defective, but unless 3023bis is
   republished right now, there's nothing to ask the IETF folks to refer

   <jar> It has to be understood that required-error is not a referent

   <JeniT> jar, I don't understand what you just said?

   JT: Section 4 -- Don't use a syntax that might overlap with one already
   in use
   ... E.g. media frag chose their syntax to avoid overlap with XPointer
   ... That was BP 10
   ... BP 11:

   <JeniT> New fragment identifier structures should be defined such that
   they can be used across media types that share the same syntax or
   semantics rather than being specific to a single media type.

   JT: This enables e.g. conneg

   <jar> How is a spec writer supposed to know what the existing
   structures are?

   <jar> what constitutes due diligence?

   AM: What does the word 'structures' mean here?

   <JeniT> A fragment identifier structure is a defined set of fragment
   identifier syntax, semantics and processing requirements

   AM: Structure should be reusable across same syn and sem. . .

   JT: Yes
   ... YL, any suggestions wrt media frag?

   YL: I think the non-overlap is good - there was a discussion about
   trying to anticipate combining when a new top-level media type comes
   out, but that didn't get done

   JT: Was there any discussion of fallback?

   YL: A bit, but only SVG was problematic, so care had to be taken wrt
   XPointer, but if SVG defines a new syntax themselves, they will have to
   take care?

   HST: See JAR's comments above?

   JT: Not sure -- you have to look at the media types you are targetting,
   and their fragid structures, and look for conflicts

   YL: But until the new rules are in place, registrations don't always
   show the frag structure syntax

   HST: When you're trying to allow for generalization, how do you know
   who might be interested?

   HST: Seems you should look at other media type registrations targeted
   at similar information

   JT: Yes, so consider the SVG XPointer scheme, which I thought was
   unnecessarily restricted just to SVG
   ... When it was targetted at image regions
   ... So perhaps it should/could have been more generic
   ... Section 5
   ... Best practices for writing documents which include identifiers
   [anchors] or which write URIs which use fragments:

   <JeniT> Publishers should ensure that structures with the same name in
   two content-negotiated representations have the same semantics.
   Equally, where two structures in content-negotiated representations
   have the same semantics, they should be given the same name.

   JT: This just reiterates what it says in Web Arch

   NM: Word-for-word?

   JT: No, restatement

   HST: Web Arch doesn't have the second clause, I don't think

   JT: Right

   HST: I like it. . .

   NM: Just wondering if this is in scope. . .
   ... "same name"?
   ... Does that mean id=, or something referenced from a URI with a

   HST: Referencable

   JT: I was trying to pull everything about fragment identifiers into one

   NM: If it said "identifiable with a fragment identifier" instead of
   "same name"

   HST: I now hear this as a friendly amendment

   NM: As written this could apply to CSS selectors

   JT: I'll fix that
   ... BP 13 is around scripting -- I think this is quite important:

   <JeniT> Scripts should not override the normal processing of fragment
   identifiers. Script-specific fragment identifiers that identify
   application state should be encoded using a syntax that does not
   conflict with that specified for the media type.

   JT: This is trying to articulate a hierarchy -- who gets first priority
   in interpreting a fragment id

   <noah> Suggest: where scripts use fragment ids to track application
   state, such usage should be provided for in the pertinent media-type

   JT: If you are going to interpret something identified by a fragment,
   do it per the media type(s). Thus if you are creating/exploiting
   for/from script usage, don't trespass on the media-type-registered

   NM: The phrase "normal processing of fragment identifiers" troubles me

   <JeniT> talk about identifying fragments rather than normal processing

   NM: The second sentence seems backwards to me
   ... It should say that the media-type reg should provide for this use
   ... So e.g. the application/html media-type reg should say "JS can use
   syntax ... for app state"

   HST: Hold on

   HST: That's just overly optimistic, isn't it?
   ... But I take your point

   <JeniT> "adhere to the guidelines specified in the media type"

   <JeniT> "if the media type doesn't give scope for scripts to do stuff
   and you really need to, at least don't clash with the media type


   <noah> 6.1 New Specifications

   <noah> All media type specifications and registrations, especially for
   new types, must specify fragment identifier semantics for both static
   use and use in active content as appropriate. The text/html and
   application/xhtml+xml media types defined for HTML5 need to define the
   use of fragment identifiers with active content.

   <noah> 6.2 Existing Specifications

   <noah> For media types that accept "active content", like HTML and SVG,
   the definition should be extended to acknowledge the fact that fragment
   identifiers might also be used (if not in contradiction with the
   'static' use of those fragment identifiers) for programmatic purposes.
   The media type registration needs to say how fragment identifiers are
   used as parameters by the active content and how they may be used to
   identify the portion of the state that is reprodu

   NM: Why should we change direction now? Everything from 3986, through
   Web Arch and the Self-Describing Web, puts a stake in the ground and
   says "say what you are going to do, and don't do what you haven't said"

   AM: Agree with NM -- we took a direction, we should follow up on it

   NM: JT?

   JT: OK, I will rephrase, and refer back to BP 4

   NM: The State finding may be useful

   JT: Yes
   ... Section 5.2 is for people creating fragids
   ... Talks about structures they could use

   <noah> Scripts should not override the normal processing of fragment
   identifiers. --> Scripts should respect(?) the normative interpretation
   of fragment identifiers, as specified in the media type registration
   for the Content-type.

   JT: names or semantically-based [e.g. SCDs] or syntactically based
   (e.g. XPointer)

   <JeniT> Authors should not use URIs with syntax-based fragment
   identifiers unless the base URI addresses a resource with a single

   HST: Is it clear that "with a single format" means not conneged

   <noah> Best Practice 14: Do Not Use Syntax-Based Fragment Identifiers
   with Multiple Content-Negotiated Formats

   <noah> Authors should not use URIs with syntax-based fragment
   identifiers unless the base URI addresses a resource with a single

   HST: I have concerns about taking conneg too seriously in this doc.
   It's not being done much. I'd be happier if I knew a constituency
   regularly producing conneg'd data.

   JT: linked data do it RDF+XML to Turtle and XML?

   NM: Non RDF XML?

   JT: No, RDF+XML, Turtle, and HTML

   NM: I think this is OK, given the clear and rather narrow definition of
   syntax-based IDs at the top

   HST: Yes, but anyone doing this is almost certainly breaking the rules
   wrt/ barenames? E.g. if I have IDs on my HTML divs, I can't reflect
   that in Turtle?

   JT: Isn't it OK if they don't resolve?

   HST: Somewhere in the record it says that Jonathan and I have disagreed
   on the interpretation of Webarch on exactly that point.

   HST: My take is OK, since turtle doesn't give anchors for barenames.
   Odder with comparison with RDF+XML

   NM: "except when it's possible to be sure that all fragments will
   resolve consistently across formats"
   ... I was heading for pushing this back into 5.1

   JT: Already there as BP 12

   NM: How do I know? I'm an author about to write an href -- I have to
   2nd-guess the source?
   ... How do I know whether it's going to conneg or not?

   JT: If there's an extension, e.g. .xml, then you know conneg isn't
   going to happen

   NM: But we have said in Auth Metadata to not do that!

   JT: Well, that's just one example, there are many ways you might get
   this information

   HST: I'd like to come back to this one

   NM: Are we under pressure here?

   <noah> From:

   JT: I would like to take the input I have and get a new draft out
   ... There is some pressure

   <noah> From:
   ious Although a URI suffix such as .jpeg or .exe plays no role in
   establishing the media type of a Web resource, such suffixes are often
   significant in operating system filenames. This inconsistency can be
   confusing to users, and may in some cases be exploited by malicious Web
   sites to cause harm.

   HST: The suffix-reg IETF draft is due out any day now, but we can't do
   anything with that in any case
   ... The main media type IETF draft is not closing right away

   <noah> ACTION: Jeni to do new draft of fragids finding - Due 2012-07-10
   [recorded in

   <trackbot> Created ACTION-729 - do new draft of fragids finding [on
   Jeni Tennison - due 2012-07-10].

Summary of Action Items

   [NEW] ACTION: Jeni to do new draft of fragids finding - Due 2012-07-10
   [recorded in
   [NEW] ACTION: Noah to find editor for copyright and linking after group
   reviews Ashok's proposals on stronger messages - Due 2012-08-12
   [recorded in


   1. http://www.w3.org/
   2. http://www.w3.org/2001/tag/2012/06/21-agenda.html
   3. http://www.w3.org/2012/06/21-tagmem-irc
   4. http://www.w3.org/2001/tag/2012/06/21-minutes.html#agenda
   5. http://www.w3.org/2001/tag/2012/06/21-minutes.html#item02
   6. http://www.w3.org/2001/tag/2012/06/21-minutes.html#item03
   7. http://www.w3.org/2001/tag/2012/06/21-minutes.html#ActionSummary
   8. http://lists.w3.org/Archives/Public/www-tag/2012Jun/0071.html
   9. http://www.w3.org/2001/tag/2012/04/02-minutes#item05
  10. http://www.w3.org/2001/tag/group/track/actions/541
  11. http://www.w3.org/2001/tag/2012/06/21-minutes.html#action01
  12. http://www.w3.org/2001/tag/doc/mimeTypesAndFragids
  13. http://www.w3.org/2001/tag/doc/mimeTypesAndFragids.html#structures
  14. http://www.w3.org/2001/tag/doc/IdentifyingApplicationState#NewSpecs
  15. http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#confusingmalicious
  16. http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#confusingmalicious
  17. http://www.w3.org/2001/tag/2012/06/21-minutes.html#action02
  18. http://www.w3.org/2001/tag/2012/06/21-minutes.html#action02
  19. http://www.w3.org/2001/tag/2012/06/21-minutes.html#action01

       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

Received on Thursday, 28 June 2012 18:00:08 UTC