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

Draft minutes from 2012-05-03 TAG telcon

From: Jeni Tennison <jeni@jenitennison.com>
Date: Thu, 3 May 2012 23:13:51 +0100
Message-Id: <54847BB2-9561-4CA4-A0AD-8E5D76F97AFF@jenitennison.com>
To: "www-tag@w3.org List" <www-tag@w3.org>

The draft minutes for today's (2012-05-03) TAG telcon are available at


and below.




      [1] http://www.w3.org/

                               - DRAFT -

   This is version has not been approved as a true record of the
   TAG's meeting and there is some risk that individual TAG
   members have been misquoted. This transcript should typically
   not be quoted, except as necessary to arrange for correction
   and approval.

              Technical Architecture Group Teleconference

03 May 2012

   See also: [2]IRC log

      [2] http://www.w3.org/2012/05/03-tagmem-irc


          Jeni, Larry, Peter, Ashok, Jonathan, Noah

          Robin, Yves, Tim

          Noah Mendelsohn

          Jeni Tennison


     * [3]Topics
         1. [4]Convene
         2. [5]Approve minutes of prior meeting(s)
         3. [6]Administrative items
         4. [7]Close pending Actions without discussion
         5. [8]ACTION-680: review of
            pe-regs-04 (note: should be the -06 version)
         6. [9]ISSUE-57 (HttpRedirections-57), ISSUE-63
            (metadataArchitecture-63) and ISSUE-14 (HttpRange-14):
            httpRange-14  URI Documentation Discovery
     * [10]Summary of Action Items

   <trackbot> Date: 03 May 2012

   <scribe> Scribe: Jeni Tennison

   <scribe> ScribeNick: JeniT


   noah: I am probably not available next week

   Ashok: could you create the agenda?

   <masinter> i volunteer to chair if Noah can't make it

   Ashok: I could then chair if you weren't available

   noah: the meeting will be going ahead 10th May

Approve minutes of prior meeting(s)

   <noah> [11]http://www.w3.org/2001/tag/2012/04/26-minutes

     [11] http://www.w3.org/2001/tag/2012/04/26-minutes

   noah: these are noted as being a draft

   masinter: I was using the minutes as a privacy example

   noah: Larry, please look at actual text if you want it to be

   masinter: that text is fine

   <masinter> did anyone else care?

   <noah> ACTION: Noah to put health warning in "Booth Script" for
   formatting minutes [recorded in

     [12] http://www.w3.org/2001/tag/2012/05/03-minutes#action01

   <trackbot> Created ACTION-703 - Put health warning in "Booth
   Script" for formatting minutes [on Noah Mendelsohn - due

   RESOLUTION: Minutes of 2012-04-26 --
   [13]http://www.w3.org/2001/tag/2012/04/26-minutes -- are

     [13] http://www.w3.org/2001/tag/2012/04/26-minutes

   <jar> as a use case, the interesting thing is what the health
   warning should say, to set an example for other health warnings

   <jar> based on what I know of TAMI etc. I think it could say a
   different thing; will follow up in email

Administrative items

   noah: we should review the DANE work

   <masinter> i've been talking to Philip Hallem-Baker (sp?)

   noah: Larry had suggested getting invited experts

   masinter: I've been talking to Philip, who has a paper on an
   alternative method, and is critical of DANE

   noah: we'd need someone in addition to him, to be an advocate
   for DANE, right?
   ... Larry, would you sort out who should come and talk to us?

   masinter: yes

   Ashok: I've been following this, and it's still ongoing
   ... it looks like there's hardly any agreement on direction
   ... I'm wondering if it's too early to look at this

   <masinter> push date of action-697 out a couple more weeks

   <jar> action-697 due 2012-05-16

   <trackbot> ACTION-697 prepare overview of DANE for TAG
   consideration due date now 2012-05-16

   masinter: it is early to come to conclusions
   ... but even so, if it's chaos it's not unreasonable for us to
   see if we could contribute to resolving it

   Ashok: then you would ask a couple of people?

   masinter: yes, I think so, I haven't yet understood enough to
   know how to bring it to the TAG
   ... so let's (Ashok and I) meet this week and see if we can
   make sense of it together

   Ashok: ok

   noah: ok, Larry will take next step with ACTION-697

Close pending Actions without discussion

   noah: ACTION-636

   <masinter> I did move the document I was working on to the WIki

   noah: updating product page which closes out Mime and the Web
   work for now

   no objections

   agreed noah can close ACTION-636

   <noah> ACTION-670?

   <trackbot> ACTION-670 -- Noah Mendelsohn to update product
   priority list to mark MIMEWeb completed after final product
   page available -- due 2012-05-08 -- OPEN


     [14] http://www.w3.org/2001/tag/group/track/actions/670

ACTION-680: review of
(note: should be the -06 version)

     [15] http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04


     [16] http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-06

   <masinter> i think -06 made changes in response to our comments

   masinter: I think they have responded to our comments
   ... the changes between -05 and -06 were the edits in response
   to our suggestions

   <noah> Could we briefly list the things they did in response to
   our requests?

   masinter: we need to publish Jeni's document as an RFC or an
   Architectural Recommendation on best practices for media type

   noah: this (media type regs) is a IETF document that will
   become a RFC or BCP, right?

   masinter: yes, right

   noah: do we need to do something else?

   masinter: we started on best practices to fragment identifiers
   ... we wanted them to refer to that normatively, but there
   wasn't time
   ... but we still need to finish that document

   <noah> ACTION-690?

   <trackbot> ACTION-690 -- Jeni Tennison to sort next steps on
   Fragment Identifiers and Mime Types -- due 2012-04-17 -- OPEN


     [17] http://www.w3.org/2001/tag/group/track/actions/690

   noah: right
   ... Jeni has the action on what we should do

   masinter: my opinion is we should finish it

   <masinter> and get it published as an architectural
   recommendation or else an IETF BCP

   <masinter> i also had two other items with regard to media
   types which aren't currently covered

   <masinter> a) file extensions, which *are* a part of web
   architecture, mentioned in MIME reigistrations, but the
   registration process isnt currently useful

   <masinter> b) 'magic numbers', since sniffing is part of web
   architecture, but the MIME registry of magic numbers isn't

   JeniT: The discussion for item 6 on the agenda is about how to
   take that forward, and what its scope should be.
   ... I think at present it's got description, but the "best
   practices" aren't pitched right.
   ... I was going to propose to refocus on what should be put
   into mime type registrations relating especially to fragment

   <Zakim> ht, you wanted to say yes, but don't lose back-story

   noah: ok, let's talk about TAG work, and then jump back to mime

   ht: yes, I think what Jeni volunteered to do would be great
   ... but don't lose the back story, put it in another document
   and reference it from the Best Practices document

   noah: I agree, keeping the back story is good

   <masinter> i would be glad to help

   noah: Do we need to set priorities relative your other work,

   JeniT: How to prioritize relative to copyright and linking

   <jar> copyright + linking more important

   masinter: they're both important, I'm willing to help on mime
   draft, but I'll want direction

   ht: since Ned won't reference the fragment identifier document,
   it takes the time pressure off

   noah: he's reluctant to reference it because it's not there

   <masinter> what's the shortest time we could publish this?

   noah: the more we do things slowly, the more we're not good
   ... this feels like something we could get something concrete
   out rapidly

   <masinter> I think the fragment identifier document is nearly

   <ht> I'm OK either way

   JeniT: feels to me like we could do something moderately
   rapidly, good timing with media type reg. document

   noah: any objections?

   <Ashok> +1

   noah: none heard, so do fragid / media type higher priority
   ... please bring product pages up to date
   ... especially if I can put it in the report

   JeniT: I will try to do that in next couple of days

   masinter: do we need to push back on media fragments group?
   ... at the web conference, I talked to Thomas, and they were
   saying it was a mistake when the group was chartered
   ... we have a draft from a WG that the folks from the IETF
   thought was laughable
   ... there's a disconnect there

   noah: what's the concern with what they've done?

   masinter: they propose that fragids have a meaning that applies
   to all registrations of a top-level type
   ... and that idea doesn't jibe with the folks who run the media
   type registries, and what they could enforce

   <masinter> it relates to item 7, in that if we expect all
   future registrations of image/* to use the media fragments
   fragmentID scheme, the mime registration document should say so

   <masinter> at one point, the rtsp scheme wanted to define
   fragment identifiers for URIs for that scheme

   <Zakim> noah, you wanted to talk about XML vs. image

   noah: we might have something to say here, which is analogous
   to the generic processing debate
   ... we could say that there's a choice for the media type
   registrations to reference that spec
   ... but if you do that, you can't have generic processors that
   understand all images
   ... with XML, which is a +xml type which is slightly different,
   we wanted to share specs, but also have generic processing
   ... with specific understanding of the subtype
   ... that story, that trade-off, without choosing sides, might
   be useful
   ... to point out that if it's just buy-in of media types
   one-by-one, you lose generic processing
   ... because other media types might choose differently

   ht: Yves story as Jeni described it is not consistent with the
   remarks in the current version of Jeni's document
   ... about the possibility of inheritance from the top
   ... the fact that Yves doesn't think it means that, and it's
   clear that it caused an aversion reaction from the IETF
   ... I think it's worth keeping in view the possibility of
   inheritance 'from the top' as in principle a coherent position

   noah: it's interesting to talk about this in terms of the major
   type and the +ext syntax
   ... certainly there's generic processing you could do on text
   for example


     [18] http://lists.w3.org/Archives/Public/www-tag/2012May/0015.html

   noah: the media fragment spec made some statements about web
   architecture that I found surprising
   ... sent in email earlier

   <masinter> fragments don't have media types

   noah: they said fragments have the same media type as the
   original representation
   ... I'd welcome getting comments back on this

   masinter: fragments don't have media types

   <masinter> fragments aren't "retrieved"

   noah: that spec says they do!

   <noah> Quoting media types draft: A further requirement put on
   a URI fragment is that the media type of the

   <noah> retrieved fragment should be the same as the media type
   of the primary

   <noah> resource.

   <masinter> "retrieved fragment" doesn't have a media type

   <ht> Fragments _could_ have media types, if the parent media
   type registration specifies that they do

   noah: I agree with Larry that they don't have a media type
   ... it might be worth going through the spec to look at these

   <masinter> we went through this with http Range

   <masinter> byte range retrieval... (need to look up)

   JeniT: I could have a look as part of the fragid & media type

   <noah> ACTION-698?

   <trackbot> ACTION-698 -- Noah Mendelsohn to schedule discussion
   of how to take forward the TAG concerns with respect to
   managing fragment identifer schemes, inheritance and overlap --
   due 2012-05-01 -- PENDINGREVIEW


     [19] http://www.w3.org/2001/tag/group/track/actions/698

   <noah> close ACTION-698

   <trackbot> ACTION-698 Schedule discussion of how to take
   forward the TAG concerns with respect to managing fragment
   identifer schemes, inheritance and overlap closed

   <noah> ACTION-690?

   <trackbot> ACTION-690 -- Jeni Tennison to sort next steps on
   Fragment Identifiers and Mime Types -- due 2012-04-17 -- OPEN


     [20] http://www.w3.org/2001/tag/group/track/actions/690

   <noah> ACTION-690 Due 2012-05-05

   <trackbot> ACTION-690 sort next steps on Fragment Identifiers
   and Mime Types due date now 2012-05-05


     [21] http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-19

   noah: anything else on the media type registration draft?

   masinter: there are two things in my original analysis that
   aren't within this
   ... one is file extensions, which aren't part of the web,
   they're mentioned in several specifications

   <noah> What do you think we/they should say about file

   masinter: a recent thing in HTML5 in file upload that talks
   about file extensions
   ... the media type registration lists extensions, but the lists
   don't correspond to what people use
   ... this is a gap that neither W3C or IETF is working on

   <jar> 4.12. Additional Information

   <jar> SHOULD File name extension(s) commonly used on one or
   more platforms to

   <jar> indicate that some file contains a given media type.

   <jar> (quoting the draft)

   noah: do you have a concrete suggestion about what should be

   masinter: I've been worried about this for years, and I'm
   trying to see if anyone else on the TAG is interested in
   pursuing this?

   <masinter> that the MIME registry for file extensions is
   incomplete, not useful, etc. but W3C specs use file extensions,
   and they're getting *more* used in specs

   noah: it's part of the work we just closed out on Mime and the

   <masinter> another thing in the same category are the 'magic

   jar: is there a registry of file extensions?

   masinter: there's no official registry of file extensions in
   IETF or W3C
   ... the packaging spec includes file extensions for use within
   packaged documents

   <noah> (and of course, different OS's have at least somewhat
   different constraints on extensions, e.g. 3 char vs unbounded.)

   masinter: we have a best practice that HTTP URIs with file
   extensions shouldn't mean anything
   ... the media type registrations should include extensions

   jar: would this be an IANA considerations thing? a request to
   make a registry?

   masinter: we could make a registry

   ht: there already is a registry, a hugely complex registry
   ... in linux

   <masinter> there are multiple registries, apache filetypes

   noah: that's not cross-OS

   ht: there's an enormous degree of overlap, except with Windows
   ... all the unix variants buy into it, including the Macs

   noah: Windows has its own, and people hack it

   ht: there is a registry, it's just not an IANA one

   <masinter> [22]http://filext.com/

     [22] http://filext.com/

   <masinter> is a web site dedicated to registering file

   noah: the IETF has a loose form, in that media type
   registrations can list extensions
   ... I just wonder if they might be checked for consistency with

   jar: that's not going to happen

   noah: you mean if I gave a file extension of 'jpeg' then they
   wouldn't object?

   masinter: there's a website [23]http://filext.com/

     [23] http://filext.com/

   <noah> FILExt is a database of file extensions and the various
   programs that use them. I

   <masinter> i'm just pointing out that this is a part of "how
   the web works" that isn't standardized, and that disagreements
   about cause problems

   <masinter> and that use from W3C specs is increasing

   jar: the way I see these registraties is that the truth comes
   from IETF and IANA just does administration
   ... we could under IANA considerations ask them to start
   keeping a registry
   ... I'm not saying it's a good idea, just it might logically
   make sense
   ... but if the information is in other places, maybe it doesn't

   noah: what should we do about this as the TAG?

   <masinter> put it on our list of "things we should do later" ?

   masinter: maybe we need a list of things that webarch doesn't
   talk about

   noah: what was the other one you had, Larry?

   masinter: magic numbers and sniffing
   ... I'm bringing these up because they are both in the media
   type reg document as something you could say

   jar: they have a SHOULD, you have to justify not saying them

   masinter: but it doesn't tell you why you would say it, or what
   the best practice is

   noah: does the TAG need to engage on this?
   ... couldn't an individual make comments on the draft?
   ... what do you want them to do, and does it involve the TAG to
   get there?

   masinter: I see people building things that don't work well
   because of inconsistencies in these areas

   noah: but what should we do?

   masinter: I'm ok with moving on

   <masinter> I don't know what else to do with those

   <masinter> At one point in an AC meeting I argued for more
   "fixing the potholes" vs. "building bridges to nowhere" and
   that file extensions and magic numbers are potholes in the web

   <ht> For the record, [24]http://mx.gw.com/mailman/listinfo/file
   is the mailing list which manages the magicnumbers/extensions
   'registry'---there is no website for this, the closest there is
   is the README file from the 'file' package, e.g.

     [24] http://mx.gw.com/mailman/listinfo/file
     [25] http://hpux.connect.org.uk/hppd/hpux/Editors/file-5.11/readme.html

   <noah> ACTION-680?

   <trackbot> ACTION-680 -- Jeni Tennison to lead TAG telcon
   review (rescheduled) of
   gs-04 -- due 2012-04-24 -- PENDINGREVIEW

     [26] http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04


     [27] http://www.w3.org/2001/tag/group/track/actions/680

   <noah> close ACTION-680

   <trackbot> ACTION-680 Lead TAG telcon review (rescheduled) of
   gs-04 closed

     [28] http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-04

ISSUE-57 (HttpRedirections-57), ISSUE-63 (metadataArchitecture-63)
and ISSUE-14 (HttpRange-14): httpRange-14  URI Documentation

   <noah> [29]http://www.w3.org/wiki/HTTPURIUseCaseMatrix

     [29] http://www.w3.org/wiki/HTTPURIUseCaseMatrix

   <noah> [30]http://www.w3.org/wiki/HTTPURIUseCases

     [30] http://www.w3.org/wiki/HTTPURIUseCases

   Ashok: Jonathan, I have a small quibble. I'm tempted to look at
   3rd row, see 1 fail, and say "ah ah". Then I go to the
   proposals and see nothing matching the left hand column entry
   "New status code"

   jar: Good point.
   ... That's an omission. Wasn't formatted as a change proposal,
   but we did get the proposal. I'll put on my "to do list" to
   document. The proposal is for something like an HTTP 209 status
   code meaning "what I'm giving you is a description, not a

   <masinter> I'm still talking to jonathan about the scenarios
   and the underlying assumptions that they seem to make (to me)

   noah: have you got feedback on the matrix from the community?

   jar: I only really asked the TAG, and haven't really got
   feedback except from a couple of TAG members

   Ashok: could you put in the left column a reference indicating
   the section in the other document?

   jar: yes, I will try
   ... if there are questions that people on this call have about
   the matrix, this might be a time to surface them, but email
   would also work
   ... I'm not sure how to review this

   noah: ideally this should lead to making a proposal
   ... it might be that not all failures are equally bad for the
   ... so you might push forward to narrow discussion to just two
   or three

   jar: we talked about forming a task group, and one has emerged
   ... Henry, Jeni and I have been exchanging email for the past
   couple of weeks
   ... we're working on a narrative for the issue behind the
   ... I have strong opinions about how to go at this
   ... I'm trying to get support from Jeni and Henry on these
   ... they have strong opinions too, so we're going to try to get
   something between us

   noah: the other thing I missed in the matrix, I wondered if
   there were things that it doesn't cover
   ... for example, aside from use case J, I was looking for
   something that would break if there was a new status code
   ... are all these deployable to some degree?

   <masinter> "deployable" has a scope.

   jar: the question is who do we give veto power to

   noah: what do proxies do if they see a status code they haven't
   seen before?

   jar: I think it's specified in the HTTP spec

   noah: doing some due diligence on what running code actually
   does would be a good idea
   ... to see if the options are actually viable
   ... many of these have fallen down when we look at what ISPs
   can do

   jar: I don't know how to do that in the matrix

   noah: I'm not saying how to format it, I'm saying do analysis
   early enough

   jar: almost no one will accept a new status code

   noah: but why? we need to capture that
   ... it makes architectural sense to me, you say it fails only
   one use case

   Ashok: browsers would have to implement it, right?

   jar: they might treat it the same as a 200
   ... one of the big complaints about the 303 is you have to do a
   song and dance around your server configuration, and that's
   what use case J is saying
   ... maybe we should talk about the other goal
   ... we have to think about how to generalise this
   ... if this is an RDF-specific problem, we need to hand it off
   to people who care about RDF
   ... draw some line to say what we think is good practice
   ... there are some things that are TAG business, and others
   that are RDF business, and a lot of the proposals look like RDF
   ... we've been talking about use case M, HTTP consistency,
   which seems like a TAG issue
   ... I have a proposal for how to do the hand off, but I want to
   wait for Henry and Jeni to agree or disagree about that
   ... unless we want to talk about this on the call, maybe we
   should put it out to committee

   Ashok: is this really a RDF problem?

   jar: it depends on what you think the problem is
   ... to me, it's a serious issue whether HTTP and RDF diverge
   ... maybe it's ok if they diverge, but that suggests they
   should be careful in the language they use
   ... so there isn't confusion about how web architecture works

   Ashok: suppose we took RDF off the table, here
   ... what would we still have?

   masinter: I don't think there would be things left

   <masinter> i think this is a 'use of RDF' problem

   <masinter> RDF doesn't have a problem, URIs don't have a

   <masinter> it's people who want to turn "statements in RDF
   using URIs" into "statements about the real world" who want to
   take a URI and have it identify something in the real world

   <jar> absolutely

   <masinter> and the problem is that URIs were never intended as
   a general mechanism for identifying things in the real world

   ht: there definitely would
   ... there are definitely things left that would matter
   ... the language that the TAG and TAG members such as TimBL
   have used for years
   ... is self-contradictory
   ... if we care about clearing up a mess that we created, we
   have to fix that
   ... and that would be true even if RDF didn't exist

   noah: I think on general principles, and given the TAG had this
   resolution years ago
   ... I think it would be helpful to explain why it's not our
   business, if it isn't
   ... for example, Larry and I didnt immedately agree about what
   HTTP status codes are used for
   ... explaining what that answer is is very much in TAG's scope
   ... especially as our last solution was to use a status code
   ... I'd like to explain what the limits are of web architecture
   and their applicability to this problem

   <masinter> people building ontologies think an ontology is a
   mechanism for turning idnetifiers for web resources into
   identifiers of concepts

   <ht> I also don't think we could just profer a new status code
   as a solution without a story behind it

   jar: it would be nice to get any bit of consensus we can on
   what's TAG business and what isn't

   noah: if there are useful back-channel discussions happening,
   maybe we should hang loose for a while

   ht: I think we have to work a bit longer towards convergence
   ... I'm the major bottleneck, probably, but I'd like another

   <noah> We're hearing that Jonathan, Henry and Jeni are working
   in the background to get some more clarity. Should we just hold
   off a couple of weeks and await progress?

   Ashok: Henry, you've spoken about the language around content
   negotiation and so on being self-contradictory
   ... do you have an idea how to fix that?

   ht: no, I don't
   ... I mentioned it because it's something I use to test
   proposed solutions
   ... because I think 'it better solve this problem too'
   ... the cardinality problem: how many resources are there?

   <Zakim> masinter, you wanted to talk about another approach

   masinter: I've been trying to pursue a different direction,
   where we have a mechanism for making statements in RDF
   ... and an implicit assumption where you can use URIs to ground
   a statement in the real world
   ... and the problem is the nature of the grounding is ambiguous
   ... and we have given conflicting advice, using status codes
   and so on
   ... the problems that we really want to talk about wrt
   publishing, linking, copyright, security, trust
   ... are not easy to explain in a world where we presume that
   there is a common understanding about how a URI identifies
   ... and if you move to a different model, where you don't think
   about the truth of statement or their meaning
   ... as something that's disembodied from the agent that is
   saying it or reading it...
   ... and look at a speech act model
   ... then you stop asking what the triple means, you look at
   ... a speaker utters an RDF assertion using URIs, a receiver
   reads an interprets it, as a speech act
   ... this is a different model, which is better suited to
   talking about the difference between copying something and
   linking to it
   ... that you don't try to interpret statements independently of
   the context in which they are stated
   ... this leaves httpRange-14 behind, because we're taking on a
   more complicated, less trusting model for communication
   ... I've been trying to think about how to express the
   copyright & linking document we've been working on
   ... if we were stating these things in RDF
   ... and that gets you beyond the status code

   <jar> This is the "choose based on context" proposal in the

   noah: how much in RDF would have to be deprecated or turned off
   to use that new model?

   masinter: we have systems that assume trust between
   ... you can't do induction unless you assume that everything is

   noah: so all the statements from DBPedia remain equally useful
   if we go down this path?

   masinter: you have to put them into context that DBPedia is
   using, where maybe they intended you to look at 303 codes and
   maybe used something else
   ... it's part of a larger framework

   noah: I'd be interested to see how far you could get on getting
   Tim to agree to this

   masinter: I think I'm making some progress on him

   jar: we have to figure out what problem we're trying to solve
   ... we've had a hard time getting focus
   ... these are all fine things to work on, but it's not what we
   started with
   ... this isn't an issue for the linked data community

   masinter: I think when you get to linked data in the real world
   ... with government agencies publishing data
   ... we will need a better model

   jar: but is that the TAG's problem?
   ... that's a problem for linked data, and they will figure it
   out for themselves
   ... right now we're doing design for nobody if we take this on

   noah: maybe if you change the ground rules, the solutions are

   masinter: I think the question being asked isn't interesting

   jar: this is why I want to get it out of the TAG

   masinter: we can say we're working on something else which is
   more important

   <masinter> i think we should drop 'findings' more than 2 years
   old if we can't bring them to community consensus

   noah: we have to be careful about how we do this after 8 or 2
   ... we could look really stupid, beating our heads on this for
   ages, and finally to say it's not our problem
   ... I would have a problem with that
   ... why did this appear to be a problem for so long?
   ... we should have figured out a long time ago that this wasn't
   our problem, if it's not
   ... I think the answer is about how to use HTTP "properly"
   ... and that is the TAG's problem

   timbl: sorry for arriving late
   ... having discussed this with jar just yesterday
   ... I think the hope has been, for me, that the TAG would be
   able to describe an architecture that included linked data
   ... the original architecture didn't: it was a hypertext
   system, it didn't include RDF
   ... the problem has been partly that there's a small overlap
   between the TAG and the RDF community
   ... a relatively small overlap in general between linked data
   and people doing things with HTTP
   ... I think RDF should use HTTP properly
   ... it may be that the niceties of how RDF works can't be
   discussed with non-RDF people
   ... so we end up with an architecture that is consistent with
   HTTP, but is more detailed and refined

   noah: one of the proposals that seems to have a low number of
   downsides is to use a new status code
   ... I would have thought that the TAG should explain whether
   that's architecturally appropriate
   ... the RDF community might separately settle on whether they
   want to do that
   ... do you think that's more than what the TAG should be doing?

   timbl: if the TAG can solve this, great, write it up
   ... I regard httpRange-14 and the 303 header as a compromise

   noah: we're discussing jar's matrix
   ... one of the proposals is to use a new status code

   <jar> 207, 208, 209

   <jar> refresh the page

   noah: I'm just probing because you seemed to be saying the TAG
   should back off because the communities were separate
   ... I would say the TAG has a role to play to say whether it's
   an appropriate to use a status code for this

   timbl: there are a lot of issues here where it's only the TAG
   who are chartered to do this
   ... but I think it would also be reasonable to just make this
   work for linked data
   ... if we had a new status code, we would have to explain how
   to do so, maybe push towards hash more strongly
   ... still have to deal with simple OGP as well
   ... there's valuable work to be done here

   noah: we're at time
   ... Jonathan, Henry and Jeni have been talking behind the
   scenes to move towards more clarity
   ... I'm inclined to wait a week or two and see what happens

   jar: agreed

   timbl: I'd be happy to be brought up to date offline

   masinter: when they come to a conclusion, they should bring it
   to us

   <noah> ACTION-691?

   <trackbot> ACTION-691 -- Jonathan Rees to prepare table as
   described in 2012-04-04 minutes, for TAG review -- due
   2012-04-24 -- PENDINGREVIEW


     [31] http://www.w3.org/2001/tag/group/track/actions/691

   <noah> close ACTION-691

   <trackbot> ACTION-691 Prepare table as described in 2012-04-04
   minutes, for TAG review closed

   masinter: eliminate from consideration all but three rows

   jar: I'm not sure we have standing to do that

   noah: you could do it as a proposal

   <noah> ACTION: Jonathan with help from Jeni and Henry to try to
   identify next steps for moving forward on httpRange-14 - Due
   2012-05-15 [recorded in

     [32] http://www.w3.org/2001/tag/2012/05/03-minutes#action02

   <trackbot> Created ACTION-704 - with help from Jeni and Henry
   to try to identify next steps for moving forward on
   httpRange-14 [on Jonathan Rees - due 2012-05-15].

   masinter: come back with at most the number of rows as the
   number of people in the subgroup

   <masinter> I don't like any of the proposals, because I don't
   like the question

   <masinter> but at least if you're going to continue to ask the
   same question, come back with at most N rows, where N is the
   size of the subgroup

   <noah> We are ADJOURNED. Informal discussion can continue.

Summary of Action Items

   [NEW] ACTION: Jonathan with help from Jeni and Henry to try to
   identify next steps for moving forward on httpRange-14 - Due
   2012-05-15 [recorded in
   [NEW] ACTION: Noah to put health warning in "Booth Script" for
   formatting minutes [recorded in

     [33] http://www.w3.org/2001/tag/2012/05/03-minutes#action02
     [34] http://www.w3.org/2001/tag/2012/05/03-minutes#action01

   [End of minutes]

    Minutes formatted by David Booth's [35]scribe.perl version
    1.136 ([36]CVS log)
    $Date: 2012/05/03 22:10:37 $

     [35] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [36] http://dev.w3.org/cvsweb/2002/scribe/

Jeni Tennison
Received on Thursday, 3 May 2012 22:14:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:44 UTC