21-mediafrag-minutes.html
31 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang='en' xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta name="generator" content=
"HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
<title>Media Fragments Working Group Teleconference -- 21 Oct
2008</title>
<link type="text/css" rel="STYLESHEET" href=
"http://www.w3.org/StyleSheets/base.css" />
<link type="text/css" rel="STYLESHEET" href=
"http://www.w3.org/StyleSheets/public.css" />
<link type="text/css" rel="STYLESHEET" href=
"http://www.w3.org/2004/02/minutes-style.css" />
<meta content="Media Fragments Working Group Teleconference"
name="Title" />
<meta content="text/html; charset=utf-8" http-equiv=
"Content-Type" />
</head>
<body>
<p><a href="http://www.w3.org/"><img src=
"http://www.w3.org/Icons/w3c_home" alt="W3C" border="0" height=
"48" width="72" /></a></p>
<h1>Media Fragments Working Group Teleconference</h1>
<h2>21 Oct 2008</h2>
<p><a href=
'http://www.w3.org/2008/WebVideo/Fragments/wiki/FirstF2FAgenda'>Agenda</a></p>
<h2><a name="attendees" id="attendees">Attendees</a></h2>
<div class="intro">
<dl>
<dt>Present</dt>
<dd>Erik, Davy, Yves, Guillaume, Silvia, Raphael, Colm_Doyle,
Fons_Kuijk, Jack, Frank</dd>
<dt>Regrets</dt>
<dt>Chair</dt>
<dd>Erik, Raphael</dd>
<dt>Scribe</dt>
<dd>Erik</dd>
</dl>
</div>
<h2>Contents</h2>
<ul>
<li>
<a href="#agenda">Topics</a>
<ol>
<li><a href="#item01">Issues</a></li>
<li><a href="#item02">URI Fragment / URI Query</a></li>
<li><a href="#item03">Admin</a></li>
<li><a href="#item04">URI Fragment / URI Query</a></li>
<li><a href="#item05">Fragment Name and
Description</a></li>
<li><a href="#item06">Status of a Media Fragment</a></li>
<li><a href="#item07">Server, Cache and Proxies</a></li>
<li><a href="#item08">Protocols</a></li>
<li><a href="#item09">Wrap-up</a></li>
</ol>
</li>
<li><a href="#ActionSummary">Summary of Action Items</a></li>
</ul>
<hr />
<div class="meeting">
<p class='phone'> </p>
<p class='phone'> </p>
<p class='irc'><<cite>raphael</cite>> trackbot, start
telcon</p>
<p class='irc'><<cite>trackbot</cite>> Date: 21 October
2008</p>
<p class='irc'><<cite>raphael</cite>> Scribenick:
raphael</p>
<p class='irc'><<cite>scribe</cite>> Scribe: Erik</p>
<p class='irc'><<cite>scribe</cite>> scribenick: erik</p>
<h3 id="item01">Issues</h3>
<p class='phone'>1. Continuity/Discontinuity</p>
<p class='phone'><cite>silvia:</cite> URI-scheme could cover
multi-part (if needed)</p>
<p class='phone'>silvia/jack: if multiple fragments in one URL,
hierarchy structure could be problem ... SMIL can do that</p>
<p class='phone'><cite>jack:</cite> something for v2?</p>
<p class='phone'><cite>raphael:</cite> still a lot of issues,
postpone a bit</p>
<p class='phone'><cite>jack:</cite> will influence syntax
somehow pretty soon</p>
<p class='phone'>conclusion for continuity/discontinuity:
postponed a bit, but keep in mind</p>
<p class='phone'>2. spatial fragment shape</p>
<p class='phone'><cite>jack:</cite> non-rectangular shape is
only important if animation is also covered</p>
<p class='phone'>silvia/davy/erik: rectangular is most
feasable, most important, easiest to implement</p>
<p class='phone'><cite>raphael:</cite> we should look at what
SVG-group did</p>
<p class='phone'>conclusion for spatial fragment shape:
rectangular shape to start with</p>
<p class='phone'>silvia/jack: non-rectangular shapes on images
are do-able, but for video rectangular is only valid use
case</p>
<p class='phone'>3. container & substreams</p>
<p class='phone'><cite>silvia:</cite> container formats are
enough to consider</p>
<p class='phone'><cite>jack:</cite> is there any important
codecs/containers missing?</p>
<p class='phone'>davy explains codecs wiki-page</p>
<p class='phone'><cite>silvia:</cite> should also add SNOW
(wavelet based) from FFMPEG</p>
<p class='irc'><<cite>Yves</cite>> <a href=
"http://svn.mplayerhq.hu/ffmpeg/trunk/doc/snow.txt?view=co">http://svn.mplayerhq.hu/ffmpeg/trunk/doc/snow.txt?view=co</a></p>
<p class='phone'><cite>silvia:</cite> also in audio codecs
framing is not deterministic</p>
<p class='phone'><cite>davy:</cite> but more easy to jump into
audio than it is to jump into video</p>
<p class='phone'><cite>silvia:</cite> MPEG-1 has different
kinds of encapsulation, good to have but more difficult to
handle<br />
... only make assumption about general structure of resource
(not about coding & decoding)<br />
... FLAC is already framed</p>
<p class='phone'>Erik will update codec page ... including
SNOW, AVS, SVC, OMS, Speex, MLP</p>
<p class='phone'><cite>Silvia:</cite> raw formats are even
easier to handle then codecs</p>
<p class='phone'>davy explains container wiki-page</p>
<p class='irc'><<cite>guillaume</cite>> raw "WAV" or
"YUV" have a more direct / linear time to byte mapping</p>
<p class='phone'>erik/davy to check if .mp4 can have references
to other files as indexing could be more complex</p>
<p class='phone'>davy/jack/raphael: player that doesn't
understand some "boxes", probably will skip it and play what it
understands</p>
<p class='phone'><cite>jack:</cite> what about encrypted
AAC?</p>
<p class='phone'><cite>silvia:</cite> DRM is another
ballgame</p>
<p class='phone'><cite>raphael:</cite> we will mention the
limitations of our solutions (cfr. DRM-stuff)</p>
<p class='phone'><cite>silvia:</cite> within OGG you always
need the header instead of mp3 for example</p>
<p class='phone'>erik/davy will update container wiki-page ...
adding AU, XVID, DIVX & check consistency with media
resource model of silvia</p>
<p class='phone'><cite>silvia:</cite> substreams are just
another point of view of fragments adressing<br />
... solve spatial & temporal adressing issue, but see that
it is extendable (generic scheme) for e.g. substreams<br />
... create a syntax spec. that is extensible</p>
<p class='phone'><cite>jack:</cite> certainly keep that in mind
when talking about syntax starts</p>
<p class='phone'>conclusion of substreams (e.g. tracks, ...):
postpone decision, but certainly create syntax that is
extensible to incorporate this at a later time</p>
<p class='phone'>4. in-context vs. out-of-context</p>
<p class='phone'><cite>jack:</cite> only jump to specific
"paragraph" in isolation or jump to "paragraph" in context of
whole document</p>
<p class='phone'><cite>silvia:</cite> just an application
issue</p>
<p class='phone'><cite>yves:</cite> applications should be
independant of our addressing scheme</p>
<p class='phone'><cite>raphael:</cite> fragment point of view
... context awareness<br />
... application point of view ... should be context independant
according to the addressing scheme</p>
<p class='phone'><cite>yves:</cite> implementation should be
able to choose (as in browsers nowadays)</p>
<p class='irc'><<cite>raphael</cite>> Example of a bad
fragment: <a href=
"http://www.techcrunch.com/2008/10/10/getting-the-unparty-started-seesmic-lays-off-13-of-staff/">
http://www.techcrunch.com/2008/10/10/getting-the-unparty-started-seesmic-lays-off-13-of-staff/</a></p>
<p class='phone'>conclusion of in-context vs. out-of-context:
we want to make sure that fragment is aware of "full"
resource</p>
<p class='irc'><<cite>raphael</cite>> scribenick:
raphael</p>
<p class='phone'>TOPICS: URI Fragment / URI Query</p>
<h3 id="item02">URI Fragment / URI Query</h3>
<p class='phone'>Yves drawing on the board</p>
<p class='phone'><cite>scribe:</cite> User requests <a href=
"http://www.example.com/foo#t=1">http://www.example.com/foo#t=1</a>,20<br />
... UA is smart, knows that the URI without the hash part will
be sent to the server<br />
... UA can ask in the local hhtp cache if the resource is
here<br />
... it requires the browser vendors do some clever things with
the hash part<br />
... browsers do that already with an XPATH expression after the
#</p>
<p class='phone'><cite>Jack:</cite> difference is here that
browsers do that before sending to the server the request of
the resources, so browsers have no clue what is the mime type
of the resource</p>
<p class='phone'><cite>Yves:</cite> case 1 = Base URI is a
video<br />
... send a range request: second 1-20<br />
... server sends back a content range: second 1-20 + the
content type<br />
... no need of the four-way handshake?</p>
<p class='phone'><cite>Silvia:</cite> I have a pretty big
problem, because of the possibility of caching the fragments in
the proxies</p>
<p class='phone'><cite>Yves:</cite> we would need dedicated
video proxies<br />
... that understand seconds?<br />
... the proxies will be able to cache it<br />
... case 2 = Base URI is text<br />
... the range unit cannot be applied to the resource<br />
... the server will provide the right content header and the
resource<br />
... in this case, the UA will seek to the id = 't=1,20' of the
text resource</p>
<p class='phone'><cite>Jack:</cite> put garbage behind the #
... the UA wil display the all resource</p>
<p class='phone'><cite>Yves:</cite> case 3 = Base URI is a
video<br />
... the server does not know how to handle range request with
seconds<br />
... will send the whole resource</p>
<p class='phone'><cite>Raphael:</cite> we can in this case do a
4-way handshake</p>
<p class='phone'><cite>Yves:</cite> case 4 = Base URI is a text
on an old fashioned web server<br />
... works as in case 2</p>
<p class='phone'>This solution is a mix between a 2-way and a
4-way handshake</p>
<p class='phone'><cite>Jack:</cite> how the case 3 works with a
old fashioned web server</p>
<p class='phone'><cite>Yves:</cite> we can have services on
proxy, that will do the work, i.e. do the cropping<br />
... in the worst case, the whole video is sent</p>
<p class='phone'><cite>Jack:</cite> what about adding http
extra headers?</p>
<p class='phone'><cite>Yves:</cite> adding extra http headers
will make old fashioned web servers ignoring them<br />
... http is a 'must ignored'<br />
... does not break previous implementations</p>
<p class='irc'><<cite>guillaume</cite>> Jack: Couldn't we
have a "must understand"?</p>
<p class='irc'><<cite>erik</cite>> Jack: our addressing
scheme should come up with half of the solution, the other half
should come from HTTP (or other) protocol</p>
<p class='phone'><cite>Silvia:</cite> look at the HTTP/1.1,
RFC2616, sec 10.4.17 ... 416 Requested Range Not
Satisfiable</p>
<p class='irc'><<cite>jackjansen</cite>> <a href=
"http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.17">
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.17</a></p>
<p class='phone'><cite>Silvia:</cite> we didn't consider that
in TemporalURI since we assumed we will not change the
browsers</p>
<p class='phone'><cite>Yves:</cite> not that a problem to
change the browsers</p>
<p class='phone'><cite>Jack:</cite> are the browser vendors the
only people we want to talk</p>
<p class='phone'><cite>Yves:</cite> browsers, media players,
proxies such as Squid<br />
... we need to talk to all of them<br />
... TAG will be happy because we are making a good use of the
'#'<br />
... I'm editor of HTTP 1.1 bis in IETF</p>
<p class='phone'><cite>Sivlia:</cite> I want to dig how we can
implement this solution<br />
... look at the RFC2396, section 4: URI References</p>
<p class='irc'><<cite>nessy</cite>> <a href=
"http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a></p>
<p class='phone'><cite>Sivlia:</cite> again a way of encoding
the mime-type of the resource in the fragment scheme</p>
<p class='phone'><cite>Jack:</cite> Larry said yesterday that
who owns the mime-type owns the def of fragment of a
resource</p>
<p class='phone'><cite>Silvia:</cite> Read the section 4 of
RFC3986 !!! the new one<br />
... the fragment is never sent to the network<br />
... oups, read the section 3.5 !!!</p>
<p class='phone'><cite>raphael:</cite> wonders if we link to
the good URI in the wiki !!! Need to check</p>
<p class='phone'><cite>Silvia:</cite> how can we define the
mime-type implicitely in the URI scheme</p>
<p class='phone'><cite>All:</cite> problem, is the '(' allowed
in a fragment of a textual document?</p>
<p class='phone'><cite>Jack:</cite> then the construct
xpath(...) would have a problem</p>
<p class='phone'><cite>Silvia:</cite> check, parenthesis is not
allowed<br />
... so the mf() scheme of MPEG-21 is fine, as well as the XPATH
scheme<br />
... we could use the same trick<br />
... Possible syntax: #fragment(..., ..., ...) and a comma
separated list</p>
<p class='phone'><cite>Jack:</cite> of course this will be a
functional notation</p>
<p class='phone'><cite>Silvia:</cite> can also use the '&'
as it is done in cgi, and we can concatenate as many as we want
parameters<br />
... we need to have a discussion whether a fragment is a
function or not</p>
<p class='phone'><cite>Jack:</cite> if want to be extensible,
we would need to have a sort of functional syntax</p>
<p class='phone'><cite>Silvia:</cite> keep it simple should be
the motto<br />
... that might throw away the multi-fragments functionality</p>
<p class='phone'><cite>Jack:</cite> we think our projection on
the time/space/track axes are commutative, all the parameters
can be applied in any order<br />
... if this is the case, we can have a flat list parameter =
value and we do not need a functional syntax<br />
... do we agree on that ?</p>
<p class='phone'><cite>Guillaume:</cite> I don't ...</p>
<p class='phone'><cite>Silvia:</cite> in the case of a
non-functional notation, I would like to have the first
character giving an hint to the UA which kind of resources we
are dealing with<br />
... I would recommend to give the very first character to do
that</p>
<p class='phone'><cite>Yves:</cite> it won't work<br />
... anybody can do the same<br />
... SVG is both image and text</p>
<p class='phone'><cite>Silvia:</cite> let's reformulate: I
would put the very first character to distinguish between an
HTML resource or non-HTML resource<br />
... I would avoid to have '(' and ')' because it implies
functional notation<br />
... we could use ':'</p>
<p class='phone'><cite>Yves:</cite> this is syntax ... it is
not important</p>
<h3 id="item03">Admin</h3>
<p class='phone'><cite>Erik:</cite> Weekly teleconference, day
and hour</p>
<p class='phone'><cite>Proposal:</cite> have the weekly telecon
on Wednesday, 10:00 AM UTC<br />
... from now on ... until we get someone from the US West coast
in the group<br />
... have the weekly telecon on Wednesday, 09:30 AM UTC</p>
<p class='phone'><a href=
"http://www.timeanddate.com/worldclock/fixedtime.html?day=05&month=11&year=2008&hour=09&min=30&sec=0&p1=0">
http://www.timeanddate.com/worldclock/fixedtime.html?day=05&month=11&year=2008&hour=09&min=30&sec=0&p1=0</a></p>
<p class='irc'><<cite>nessy</cite>> +1</p>
<p class='irc'><<cite>erik</cite>> +1</p>
<p class='irc'><<cite>davy</cite>> +1</p>
<p class='irc'><<cite>Yves</cite>> +1</p>
<p class='irc'><<cite>guillaume</cite>> +1</p><a name=
"action01" id="action01"></a>
<p class='irc'><<cite>scribe</cite>>
<strong>ACTION:</strong> Yves to request a new time slot on the
Zakim bridge [recorded in <a href=
"http://www.w3.org/2008/10/21-mediafrag-minutes.html#action01">http://www.w3.org/2008/10/21-mediafrag-minutes.html#action01</a>]</p>
<p class='irc'><<cite>trackbot</cite>> Created ACTION-7 -
Request a new time slot on the Zakim bridge [on Yves Lafon -
due 2008-10-28].</p>
<p class='phone'><cite>Erik:</cite> 2nd F2F meeting will be in
Ghent in Belgium, on 9 and 10 of December<br />
... Observers will be allowed</p>
<p class='phone'>Quick straw poll: 6 people will make it +
possibly more</p>
<p class='phone'><cite>scribe:</cite> Silvia and Guillaume will
participate remotely</p><a name="action02" id="action02"></a>
<p class='irc'><<cite>scribe</cite>>
<strong>ACTION:</strong> setup Zakim for the 2nd face to face
meeting [recorded in <a href=
"http://www.w3.org/2008/10/21-mediafrag-minutes.html#action02">http://www.w3.org/2008/10/21-mediafrag-minutes.html#action02</a>]</p>
<p class='irc'><<cite>trackbot</cite>> Sorry, couldn't
find user - setup</p>
<p class='phone'>Possible groups we will interact with: SYMM,
SVG, HTML5, TAG, HTTP</p>
<p class='phone'><cite>Raphael:</cite> we need to agree on a
roadmap<br />
... for creating editor's draft to have quickly feedback<br />
... I would suggest to have a document that contains the Use
Cases + descriptions + sketch of the solutions we have
foreseen<br />
... 2-way handshake, 4-way handshake, etc.</p>
<p class='phone'><cite>Silvia:</cite> I can create a new wiki
page cleaning up the existing UCs</p>
<h3 id="item04">URI Fragment / URI Query</h3>
<p class='phone'><cite>Guillaume:</cite> go back to the
commutative property of a non functional syntax for expressing
the syntax of the fragment</p>
<p class='phone'><cite>Jack:</cite> first investigate the '#'
scenario<br />
... wait for the feedback of the other groups<br />
... see if it works before considering the '?'</p>
<p class='phone'>Everybody nodds and agrees with Jack</p>
<p class='phone'><cite>Silvia:</cite> in a way, we have defined
how to do this communication server side with a '#'</p>
<h3 id="item05">Fragment Name and Description</h3>
<p class='phone'><cite>Problems:</cite> gives a name to a
fragment, how to communicate this to the server?</p>
<p class='phone'><cite>Silvia:</cite> URI#;name=test ... a
Range request: fragment test<br />
... and then a 4-way handshake</p>
<p class='phone'><cite>Jack:</cite> do we envision that the UA
will pass to the server what is after the hash through http
headers?</p>
<p class='phone'><cite>Silvia:</cite> be carreful of the number
of new http headers we will create<br />
... same http header but new headers</p>
<p class='irc'><<cite>nessy</cite>> <a href=
"http://www.iana.org/assignments/message-headers/perm-headers.html">
http://www.iana.org/assignments/message-headers/perm-headers.html</a></p>
<p class='phone'><cite>Raphael:</cite> we consider the names
will be unique<br />
... if there are multiple occurences of a name within the same
resource, then the UA might go to the first one</p>
<p class='phone'><cite>Jack:</cite> are these names UTF-8
encoded strings?<br />
... can we have Japanese characters into these names?<br />
... I want to do names ... and moreover, the syntax can cope
with any names which are allowable in other media formats</p>
<p class='irc'><<cite>nessy</cite>> quicktime example:
<a href=
"http://peepcode.com/pages/quicktime-chapter-track">http://peepcode.com/pages/quicktime-chapter-track</a></p>
<p class='irc'><<cite>nessy</cite>> jumping directly to
chapters inside a quicktime chapter track</p>
<p class='phone'><cite>Jack:</cite> we might need some quoting
characters for the names<br />
... if there is a quicktime addressing naming scheme, we need
to learn about</p>
<p class='phone'><cite>Silvia:</cite> will look for</p>
<h3 id="item06">Status of a Media Fragment</h3>
<p class='irc'><<cite>guillaume</cite>> "frame label" or
"named anchors" for Flash <a href=
"http://noscope.com/journal/2004/04/named-anchors">http://noscope.com/journal/2004/04/named-anchors</a>
looking for example</p>
<p class='phone'><cite>Raphael:</cite> might be relevant if we
want to explicitely create new resources</p>
<p class='phone'><cite>Yves:</cite> explains the latest
Internet Draft, with the HTTP Header Linking<br />
... can be used to point to the parent resource</p><a name=
"action03" id="action03"></a>
<p class='irc'><<cite>scribe</cite>>
<strong>ACTION:</strong> Yves to look at more deeply if it is
possible to use the current HTTP header linking for a fragment
to point to its parent resource [recorded in <a href=
"http://www.w3.org/2008/10/21-mediafrag-minutes.html#action03">http://www.w3.org/2008/10/21-mediafrag-minutes.html#action03</a>]</p>
<p class='irc'><<cite>trackbot</cite>> Created ACTION-8 -
Look at more deeply if it is possible to use the current HTTP
header linking for a fragment to point to its parent resource
[on Yves Lafon - due 2008-10-28].</p>
<p class='irc'><<cite>nessy</cite>> xpointer registry
<a href=
"http://www.w3.org/2005/04/xpointer-schemes/">http://www.w3.org/2005/04/xpointer-schemes/</a></p>
<p class='phone'><cite>Jack:</cite> there is XPointer ... why
is it still a WD since 2001?</p>
<p class='irc'><<cite>jackjansen</cite>> Xpointer spec:
<a href=
"http://www.w3.org/TR/WD-xptr">http://www.w3.org/TR/WD-xptr</a></p>
<p class='phone'><cite>Yves:</cite> I will ask Liam Quin what's
going on</p>
<p class='irc'><<cite>Yves</cite>> <a href=
"http://www.w3.org/TR/xptr-framework/">http://www.w3.org/TR/xptr-framework/</a></p>
<p class='irc'><<cite>jackjansen</cite>> XPointer rec
that google cannot find: <a href=
"http://www.w3.org/TR/2003/REC-xptr-framework-20030325/">http://www.w3.org/TR/2003/REC-xptr-framework-20030325/</a></p>
<p class='phone'><cite>Silvia:</cite> is XPointer only valid
for XML documents?</p>
<p class='phone'><cite>Jack:</cite> yep, you're right</p>
<p class='phone'><cite>Raphael:</cite> XML is a structured
document, this is not our case, should not copy the syntax</p>
<p class='phone'><cite>All:</cite> looking at <a href=
"http://www.ietf.org/rfc/rfc5147.txt">http://www.ietf.org/rfc/rfc5147.txt</a></p>
<p class='phone'><cite>Silvia:</cite> should be added to my
current #<something> list<br />
... '#<alpha>' [HTML], '#mf(...)' [MPEG-21], '#line=' or
'#char=' [RFC5147]</p>
<p class='irc'><<cite>jackjansen</cite>> One of the
rfc5147 authors had an article at Hypertext 2005 on the
subject, see <a href=
"http://dret.net/netdret/docs/wilde-ht2005-textfrag.pdf">http://dret.net/netdret/docs/wilde-ht2005-textfrag.pdf</a></p>
<p class='irc'><<cite>jackjansen</cite>> (refers to
various people we know, too:-)</p>
<h3 id="item07">Server, Cache and Proxies</h3>
<p class='phone'>It is desirable that new and old proxies are
able to cache fragments</p>
<p class='phone'><cite>Yves:</cite> a proxy does not
necessarily cache only resources<br />
... should not be a problem with the solution we have
sketched</p>
<h3 id="item08">Protocols</h3>
<p class='phone'>RTSP has a scheme for temporal URI ... but not
for spatial URI</p>
<p class='phone'><cite>Silvia:</cite> we need to look at how
they do that and potentially tell them to adopt our scheme</p>
<p class='phone'><cite>Davy:</cite> shoutcast should work over
http</p>
<p class='phone'><cite>Guillaume:</cite> mms is huge</p>
<p class='irc'><<cite>davy</cite>> scribenick: davy</p>
<h3 id="item09">Wrap-up</h3>
<p class='irc'><<cite>jackjansen</cite>> Two papers on
potential use cases for fragment (please don't share too widely
just now, definitive versions later):</p>
<p class='irc'><<cite>jackjansen</cite>> <a href=
"http://homepages.cwi.nl/~jack/presentations/smilstate-for-rwab.pdf">
http://homepages.cwi.nl/~jack/presentations/smilstate-for-rwab.pdf</a></p>
<p class='irc'><<cite>jackjansen</cite>> <a href=
"http://homepages.cwi.nl/~jack/presentations/mm08sharing-for-mf.pdf">
http://homepages.cwi.nl/~jack/presentations/mm08sharing-for-mf.pdf</a></p>
<p class='phone'><cite>raphael:</cite> the following should be
in a UC & requirements doc</p>
<p class='phone'>1. Addressing</p>
<p class='phone'>3 dimensions: temporal, spatial, track</p>
<p class='phone'><cite>scribe:</cite> another dimension: named
fragments</p>
<p class='phone'>2. UA -> Server communication</p>
<p class='phone'><cite>scribe:</cite> only for http<br />
... 2-way handshake and 4-way handshake</p>
<p class='phone'><cite>jack:</cite> use cases should be
described before this</p>
<p class='phone'><cite>raphael:</cite> silvia will clean up the
wiki, at next teleconf, we will see what we have and take a
decision<br />
... description of the use cases could be used as examples for
the addressing part</p>
<p class='phone'><cite>jack:</cite> should existing
technologies be present in the doc?</p>
<p class='phone'><cite>raphael:</cite> that would be great, but
we will not have the time before the second f2f<br />
... it is a todo<br />
... smil, svg view, mpeg-21, temporal uri, ...</p>
<p class='phone'><cite>silvia:</cite> does SMIL have an
addressing scheme? If not, it should not be addressed</p>
<p class='phone'><cite>guillaume:</cite> point is what does the
technologies already do</p>
<p class='phone'><cite>jack:</cite> indeed, think
functionality</p>
<p class='phone'><cite>raphael:</cite> URI solutions: XPointer,
RFC3986, Temporal URI, SVG view, MPEG-21 Part 17<br />
... non-URI solutions: SMIL, SVG, MPEG-7</p>
<p class='phone'><cite>silvia:</cite> bottom-line is about
fragment identification possibilities by comparing these
technologies</p>
<p class='phone'><cite>jack:</cite> also add TimedText and CMML
to the non-URI solutions</p>
<p class='phone'><cite>silvia:</cite> add HTML 5</p>
<p class='phone'><cite>raphael:</cite> add RTSP to point 2
(UA->Server communication)</p>
<p class='irc'><<cite>jun</cite>> PDF Open Parameters:
<a href=
"http://partners.adobe.com/public/developer/en/acrobat/PDFOpenParameters.pdf">
http://partners.adobe.com/public/developer/en/acrobat/PDFOpenParameters.pdf</a></p>
<p class='phone'><cite>raphael:</cite> what about MMS and all
the P2P protocols (e.g., subcast, pplive, ...)</p>
<p class='phone'><cite>silvia:</cite> find out if these specs
support fragments</p>
<p class='phone'><cite>erik:</cite> are these P2P protocols
open?</p>
<p class='phone'><cite>raphael:</cite> yes, I think so, they
are mainly built by Chinese people</p>
<p class='phone'><cite>davy:</cite> is MMS not depricated?</p>
<p class='irc'><<cite>jackjansen</cite>> WMP11 does play
MMS: <a href=
"http://www.tipandtrick.net/2008/solution-to-windows-media-player-11-wmp11-cannot-stream-and-play-mms-media-protocol-in-vista/">
http://www.tipandtrick.net/2008/solution-to-windows-media-player-11-wmp11-cannot-stream-and-play-mms-media-protocol-in-vista/</a></p>
<p class='phone'><cite>silvia:</cite> most protocols will have
http or rtsp+udp as underlaying layer</p>
<p class='phone'><cite>raphael:</cite> in other groups: the
whole group is editor<br />
... is this the solution we want?</p>
<p class='phone'><cite>silvia:</cite> we are a small group, so
it would not be a big problem</p>
<p class='phone'><cite>raphael:</cite> editor as group, then no
explicit names are given</p>
<p class='phone'><cite>jack:</cite> are editors the text
writers or the contributers?</p>
<p class='phone'><cite>yves:</cite> there is also an
acknowledgements section</p>
<p class='phone'><cite>raphael:</cite> I volunteer to write
about point 2</p>
<p class='phone'><cite>jack:</cite> related technologies: we
should have a comparison based on point 1<br />
... I will prepare a first version of point 3, erik & davy
prepare a second version<br />
... is creating a movie which will be used as test case for the
technologies</p>
<p class='phone'><cite>guillaume:</cite> I also want to add
some examples for existing technologies</p>
<p class='phone'><cite>raphael:</cite> could we have some dummy
implementations for point 2</p>
<p class='phone'><cite>yves:</cite> I have a Java
implementation of a web server</p>
<p class='phone'><cite>raphael:</cite> is there any existing
Java cropping software?</p>
<p class='phone'><cite>silvia:</cite> there is one for mp3</p>
<p class='phone'><cite>yves:</cite> we would also need
customization of the browser code</p>
<p class='phone'><cite>erik:</cite> all doc preparation on the
wiki</p>
<p class='phone'><cite>guillaume:</cite> introduce 4.
Syntax</p>
<p class='phone'><cite>raphael:</cite> adjourns the meeting</p>
</div>
<h2><a name="ActionSummary" id="ActionSummary">Summary of Action
Items</a></h2><!-- Action Items -->
<strong>[NEW]</strong> <strong>ACTION:</strong> setup Zakim for
the 2nd face to face meeting [recorded in <a href=
"http://www.w3.org/2008/10/21-mediafrag-minutes.html#action02">http://www.w3.org/2008/10/21-mediafrag-minutes.html#action02</a>]<br />
<strong>[NEW]</strong> <strong>ACTION:</strong> Yves to look at
more deeply if it is possible to use the current HTTP header
linking for a fragment to point to its parent resource [recorded
in <a href=
"http://www.w3.org/2008/10/21-mediafrag-minutes.html#action03">http://www.w3.org/2008/10/21-mediafrag-minutes.html#action03</a>]<br />
<strong>[NEW]</strong> <strong>ACTION:</strong> Yves to request a
new time slot on the Zakim bridge [recorded in <a href=
"http://www.w3.org/2008/10/21-mediafrag-minutes.html#action01">http://www.w3.org/2008/10/21-mediafrag-minutes.html#action01</a>]<br />
<br />
[End of minutes]<br />
<hr />
<address>
Minutes formatted by David Booth's <a href=
"http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm">
scribe.perl</a> version 1.133 (<a href=
"http://dev.w3.org/cvsweb/2002/scribe/">CVS log</a>)<br />
$Date: 2008/10/26 10:50:37 $
</address>
</body>
</html>