Larry: In the last week, the IETF area directors have got together with the wg chairs to push the work forward.

17:12:46 [jar]

jar has joined #tagmem

17:12:53 [noah]

Let me state a bit more forcefully on WebApps: I don't think our level of investment and rate of progress has been consistent with our agreement that significant writing on WebApps would be one of our major goals for the year.

17:13:02 [jar]

zakim, who is on the call

17:13:02 [Zakim]

I don't understand 'who is on the call', jar

17:13:03 [DKA]

Henry: I feel we can't usefully respond to Roy without knowing if your idea for re-architecting the situation has support.

17:13:09 [Zakim]

-jrees

17:13:20 [noah]

I intend to work with TAG members in Sept to see whether serious writing can be done in time for discussion at the F2F.

17:13:33 [DKA]

Larry: The problem is: there's some work that needs to get done to resolve the differences between what the specs currently say and what really happens and what should happens...

17:13:57 [DKA]

Larry: also there is a venue discussion (w3c-whatwg-ieft).

17:14:01 [Zakim]

+jrees

17:14:08 [DKA]

... or the unicode consortium...

17:14:10 [jar]

zakim, mute jrees

17:14:10 [Zakim]

jrees should now be muted

17:14:17 [ht]

LM, last spring during an MIT TAG meeting we walked together to the pub, and you described your ideas for reworking the whole idea of URI grammar

17:14:18 [Yves]

s/ieft/ietf

17:14:46 [DKA]

Larry: the only rational way of making progress is to start doing some of the work...

Larry: the driver for making this happen is IDN - because if you translate from an IRI with an international name not in ascii to a URI then you get something hex-encoded which you have to unencode in order to IDN it... which presents some problems.

DKA: Workshop headlines: 1) very well attended, some reported it as most comprehensive in 5 years.

17:23:07 [noah]

DKA: Participation from academic groups, good representation from IETF

17:23:41 [noah]

DKA: We discussed need for better coordination between the IAB and the TAG...look for better progress now that summer is over

17:23:41 [Zakim]

-jrees

17:24:02 [Zakim]

+jrees

17:24:32 [noah]

DKA: There was lots of focus on device APIs. What's been learned from geolocation api deployment. Should privacy information be carried along with device data (e.g. location) in the context of an API call. Also a UI dimension.

17:24:59 [jar]

zakim, unmute jrees

17:24:59 [Zakim]

jrees was not muted, jar

17:25:17 [noah]

DKA: Privacy questions may have to be asked at time that user is asked for permission to collect data.

17:26:40 [noah]

DKA: We also discussed "privacy rulesets", presented by ????. Creative commons-like model that allows users to pick from standardized options for privacy settings.

17:27:13 [noah]

DKA: Can link a license for that piece of data, the link being carried along in user agent and onward into the network. Can indicate preference for allowing 3rd party access, etc.

17:29:09 [noah]

DKA: In summary, it was a very good opportunity for discussion. We probably achieved somewhat less consensus than I hoped, but the topics discussed were very pertinent for the DAP F2F that followed immediately after the workshop. Chairs reported it was valuable.

17:29:36 [DKA_]

DKA_ has joined #tagmem

17:30:11 [noah]

DKA: Next steps are that we need to figure out coordination between TAG and Internet Architecture Board. I could take an action.

17:30:50 [noah]

ACTION: Appelquist to coordinate with IAB regarding next steps on privacy policy

DKA: At this point, I'm not sure how much energy I have to push this forward.

17:41:08 [noah]

Chair is curious whether anyone else thinks this is high value?

17:41:19 [noah]

We need to settle soon so travel can be arranged.

17:41:26 [noah]

We also need to reach out to other attendees.

17:41:40 [noah]

I remain somewhat skeptical, but maybe I'm being too conservative.

17:42:35 [johnk]

I still think it's a good idea, but I don't have the time to do anything any more prior to October

17:42:42 [DKA_]

Tim: We could pick well-known established architects and/or people who have been making decisions that we care about...

17:43:02 [DKA_]

Noah: What kind of format and invite list would you have in mind?

17:43:41 [DKA_]

Tim: For format: maybe get people we don't know to present what the most important properties that we haven't mentioned in the architecture document?

17:43:53 [DKA_]

Noah: Invitation-only? Or open to anyone who signs up?

17:44:03 [DKA_]

Noah: Day-long thing? or Smaller meetings?

17:44:19 [DKA_]

... what kind of discussion are we trying to foster with whom?

17:45:37 [noah]

DKA: Could do day long, or just invite experts.

17:45:48 [noah]

DKA: Logistics would be much easier.

17:47:08 [DKA_]

Noah: As I think about pulling this together - within about 2 weeks we need to know which days we need to be on the west coast. Currently we have 19th-21st. If anyone needs to come on the 18th [e.g.] then we need to know in 2 weeks.

17:47:39 [DKA_]

... option B (invited experts coming to talk to us) is less difficult.

17:47:55 [DKA_]

... Anyone want to push for a full-day developer-camp style thing? If not, I propose we let it go...

17:49:02 [DKA_]

Noah: Anyone else interested in working with Dan on option (A) - a bigger developer camp on a different day?

17:49:31 [DKA_]

Tim: My concern about the "big" one is peoples' time may already be committed.

17:50:03 [Zakim]

+jrees

17:50:16 [DKA_]

Noah: What I'm hearing is it doesn't work... If you have ideas for other things that might fit in the 3 days - but inclined to let go.

RDF isn't about parts of documents, but things in this case the concept of title

18:04:14 [timbl]

so C has no infor about C#D

18:04:21 [timbl]

C#D basically does not exist

18:04:40 [DKA_]

Tim: RDF doesn't use anchors.

18:05:05 [DKA_]

Tim: If it was a hypertext document you'd be looking for an anchor...

18:05:21 [timbl]

Theer is information about A

18:05:28 [DKA_]

... it didn't define a local name - it used the fully qualified URL which has purl.org in it - about "a"

18:05:30 [timbl]

Ther is no #B in this example

18:06:32 [DKA_]

Tim: [in the current state of affairs you would be forced to write code that ignores these fragment identifiers - which is not good]

18:07:15 [ht]

q+ to ask how the situation would change if the reply had been a 303

18:07:21 [DKA_]

Tim: I've concluded from HTTP that I can use that URI to talk about this document...

18:07:31 [ht]

ack ht

18:07:31 [Zakim]

ht, you wanted to ask how the situation would change if the reply had been a 303

18:08:05 [DKA_]

Henry: What you're saying is that there are two problems here - one is that there a 302 and the other is that there is a hash in the response. What if the first were fixed - a 303 response but still a hash.

18:08:36 [DKA_]

Tim: Then I would have required C#D to identify a document - again, I am expecting a document from the 303.

18:09:23 [timbl]

From the 302 and the 200 my code concludes that C is a document and A is a document

18:09:26 [DKA_]

Tim: Yes, they could have done a 303 but then give me a document about that other document - for example a document that provides me a SPARLQL query...

18:09:57 [DKA_]

Henry: But I though the point of the http range 14 finding was that you get a document that doesn't pretend to be what you requested...

18:10:41 [DKA_]

Henry: it is 303 that we recommend in http range 14 - yes?

18:10:51 [Yves]

I would note that one of the option was to delegate the "fragment combination" to the mime type definition. RDF can tell its story there, like ignoring the #D part (but you know that only when you dereference the URI)

18:10:51 [DKA_]

Tim: Yes where the original is a predicate.

18:11:03 [timbl]

for teh case where the original is a thing like dublin or the concpet of a title.

18:11:51 [DKA_]

Henry: We've got a URI for Dublin - of course we don't get Dublin back, bur we get a 303 to a document that says it's about Dublin: RDF serialized as XML. In that document it says it's about Dublin.

18:12:26 [DKA_]

Henry: Next question - I'm not convinced that the range 14 finding envisaged RDF that was not ONLY about Dublin.

18:12:28 [Zakim]

-jrees

18:12:54 [DKA_]

Tim: No; there are lots of cases where people wrote an ontology in one file and they've used a slash in their URIs but all the URIs redirect to the same file...

18:13:29 [DKA_]

Henry: Someone might think - "actually this document contains info on every city in Ireland then I should put a hash on it to direct me to the part of that document about Dublin"

18:13:43 [DKA_]

Tim: But RDF documents don't have parts.

18:14:07 [DKA_]

Henry: But RDF tells me what the semantics of # are ?

18:15:22 [Yves]

semantic of # should be described in the application/rdf+xml type, no ?

18:16:32 [DKA_]

Tim: the RDF spec says: when you get one of these things you parse it - it tells you how to parse it when you get ... (?)

18:17:08 [DKA_]

... the tutorials show you the fragment identifier is a local identifier in a local name space...

18:17:40 [DKA_]

... there could be no other semantics to fragment IDs [than what the RDF spec states].

18:17:50 [DKA_]

Tim: The C#D issue is up the stack a bit.

18:18:33 [DKA_]

Henry: I was trying to see if based on a reasonable reading, someone in the position of the Purl people might think that putting the # on was doing the right thing. I think they did.

18:19:14 [DKA_]

Tim: It may well be that if we got back to [Purl] then they could tweak their system accordingly.

18:19:23 [DKA_]

Tim: Anyone know the webmaster at dublin core?

18:19:36 [DKA_]

Tim: Anyone know anyone else who does this? Redirecting to a #?

18:20:12 [DKA_]

Henry: [points the finger at Yves]

18:20:26 [noah]

ACTION-456?

18:20:26 [trackbot]

ACTION-456 -- Yves Lafon to locate past HTTP WG discussion on Location: A#B change, and make the TAG aware of it -- due 2010-08-17 -- PENDINGREVIEW

On the 2 Sept 2010 call, Larry decided that what he'd like is TAG endorsement of this as a submission to the IETF. He is willing to put it in IETF draft form. We agreed to schedule (soon) discussion of TAG endorsement for an IETF submission.