<raphael> trackbot, start telcon
<trackbot> Date: 21 October 2008
<raphael> Scribenick: raphael
<scribe> Scribe: Erik
<scribe> scribenick: erik
1. Continuity/Discontinuity
silvia: URI-scheme could cover multi-part (if needed)
silvia/jack: if multiple fragments in one URL, hierarchy structure could be problem ... SMIL can do that
jack: something for v2?
raphael: still a lot of issues, postpone a bit
jack: will influence syntax somehow pretty soon
conclusion for continuity/discontinuity: postponed a bit, but keep in mind
2. spatial fragment shape
jack: non-rectangular shape is only important if animation is also covered
silvia/davy/erik: rectangular is most feasable, most important, easiest to implement
raphael: we should look at what SVG-group did
conclusion for spatial fragment shape: rectangular shape to start with
silvia/jack: non-rectangular shapes on images are do-able, but for video rectangular is only valid use case
3. container & substreams
silvia: container formats are enough to consider
jack: is there any important codecs/containers missing?
davy explains codecs wiki-page
silvia: should also add SNOW (wavelet based) from FFMPEG
<Yves> http://svn.mplayerhq.hu/ffmpeg/trunk/doc/snow.txt?view=co
silvia: also in audio codecs framing is not deterministic
davy: but more easy to jump into audio than it is to jump into video
silvia: MPEG-1 has different
kinds of encapsulation, good to have but more difficult to
handle
... only make assumption about general structure of resource
(not about coding & decoding)
... FLAC is already framed
Erik will update codec page ... including SNOW, AVS, SVC, OMS, Speex, MLP
Silvia: raw formats are even easier to handle then codecs
davy explains container wiki-page
<guillaume> raw "WAV" or "YUV" have a more direct / linear time to byte mapping
erik/davy to check if .mp4 can have references to other files as indexing could be more complex
davy/jack/raphael: player that doesn't understand some "boxes", probably will skip it and play what it understands
jack: what about encrypted AAC?
silvia: DRM is another ballgame
raphael: we will mention the limitations of our solutions (cfr. DRM-stuff)
silvia: within OGG you always need the header instead of mp3 for example
erik/davy will update container wiki-page ... adding AU, XVID, DIVX & check consistency with media resource model of silvia
silvia: substreams are just
another point of view of fragments adressing
... solve spatial & temporal adressing issue, but see that
it is extendable (generic scheme) for e.g. substreams
... create a syntax spec. that is extensible
jack: certainly keep that in mind when talking about syntax starts
conclusion of substreams (e.g. tracks, ...): postpone decision, but certainly create syntax that is extensible to incorporate this at a later time
4. in-context vs. out-of-context
jack: only jump to specific "paragraph" in isolation or jump to "paragraph" in context of whole document
silvia: just an application issue
yves: applications should be independant of our addressing scheme
raphael: fragment point of view
... context awareness
... application point of view ... should be context independant
according to the addressing scheme
yves: implementation should be able to choose (as in browsers nowadays)
<raphael> Example of a bad fragment: http://www.techcrunch.com/2008/10/10/getting-the-unparty-started-seesmic-lays-off-13-of-staff/
conclusion of in-context vs. out-of-context: we want to make sure that fragment is aware of "full" resource
<raphael> scribenick: raphael
TOPICS: URI Fragment / URI Query
Yves drawing on the board
scribe: User requests http://www.example.com/foo#t=1,20
... UA is smart, knows that the URI without the hash part will
be sent to the server
... UA can ask in the local hhtp cache if the resource is
here
... it requires the browser vendors do some clever things with
the hash part
... browsers do that already with an XPATH expression after the
#
Jack: 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
Yves: case 1 = Base URI is a
video
... send a range request: second 1-20
... server sends back a content range: second 1-20 + the
content type
... no need of the four-way handshake?
Silvia: I have a pretty big problem, because of the possibility of caching the fragments in the proxies
Yves: we would need dedicated
video proxies
... that understand seconds?
... the proxies will be able to cache it
... case 2 = Base URI is text
... the range unit cannot be applied to the resource
... the server will provide the right content header and the
resource
... in this case, the UA will seek to the id = 't=1,20' of the
text resource
Jack: put garbage behind the # ... the UA wil display the all resource
Yves: case 3 = Base URI is a
video
... the server does not know how to handle range request with
seconds
... will send the whole resource
Raphael: we can in this case do a 4-way handshake
Yves: case 4 = Base URI is a text
on an old fashioned web server
... works as in case 2
This solution is a mix between a 2-way and a 4-way handshake
Jack: how the case 3 works with a old fashioned web server
Yves: we can have services on
proxy, that will do the work, i.e. do the cropping
... in the worst case, the whole video is sent
Jack: what about adding http extra headers?
Yves: adding extra http headers
will make old fashioned web servers ignoring them
... http is a 'must ignored'
... does not break previous implementations
<guillaume> Jack: Couldn't we have a "must understand"?
<erik> Jack: our addressing scheme should come up with half of the solution, the other half should come from HTTP (or other) protocol
Silvia: look at the HTTP/1.1, RFC2616, sec 10.4.17 ... 416 Requested Range Not Satisfiable
<jackjansen> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.17
Silvia: we didn't consider that in TemporalURI since we assumed we will not change the browsers
Yves: not that a problem to change the browsers
Jack: are the browser vendors the only people we want to talk
Yves: browsers, media players,
proxies such as Squid
... we need to talk to all of them
... TAG will be happy because we are making a good use of the
'#'
... I'm editor of HTTP 1.1 bis in IETF
Sivlia: I want to dig how we can
implement this solution
... look at the RFC2396, section 4: URI References
<nessy> http://www.ietf.org/rfc/rfc3986.txt
Sivlia: again a way of encoding the mime-type of the resource in the fragment scheme
Jack: Larry said yesterday that who owns the mime-type owns the def of fragment of a resource
Silvia: Read the section 4 of
RFC3986 !!! the new one
... the fragment is never sent to the network
... oups, read the section 3.5 !!!
raphael: wonders if we link to the good URI in the wiki !!! Need to check
Silvia: how can we define the mime-type implicitely in the URI scheme
All: problem, is the '(' allowed in a fragment of a textual document?
Jack: then the construct xpath(...) would have a problem
Silvia: check, parenthesis is not
allowed
... so the mf() scheme of MPEG-21 is fine, as well as the XPATH
scheme
... we could use the same trick
... Possible syntax: #fragment(..., ..., ...) and a comma
separated list
Jack: of course this will be a functional notation
Silvia: can also use the '&'
as it is done in cgi, and we can concatenate as many as we want
parameters
... we need to have a discussion whether a fragment is a
function or not
Jack: if want to be extensible, we would need to have a sort of functional syntax
Silvia: keep it simple should be
the motto
... that might throw away the multi-fragments functionality
Jack: we think our projection on
the time/space/track axes are commutative, all the parameters
can be applied in any order
... if this is the case, we can have a flat list parameter =
value and we do not need a functional syntax
... do we agree on that ?
Guillaume: I don't ...
Silvia: 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
... I would recommend to give the very first character to do
that
Yves: it won't work
... anybody can do the same
... SVG is both image and text
Silvia: let's reformulate: I
would put the very first character to distinguish between an
HTML resource or non-HTML resource
... I would avoid to have '(' and ')' because it implies
functional notation
... we could use ':'
Yves: this is syntax ... it is not important
Erik: Weekly teleconference, day and hour
Proposal: have the weekly telecon
on Wednesday, 10:00 AM UTC
... from now on ... until we get someone from the US West coast
in the group
... have the weekly telecon on Wednesday, 09:30 AM UTC
<nessy> +1
<erik> +1
<davy> +1
<Yves> +1
<guillaume> +1
<scribe> ACTION: Yves to request a new time slot on the Zakim bridge [recorded in http://www.w3.org/2008/10/21-mediafrag-minutes.html#action01]
<trackbot> Created ACTION-7 - Request a new time slot on the Zakim bridge [on Yves Lafon - due 2008-10-28].
Erik: 2nd F2F meeting will be in
Ghent in Belgium, on 9 and 10 of December
... Observers will be allowed
Quick straw poll: 6 people will make it + possibly more
scribe: Silvia and Guillaume will participate remotely
<scribe> ACTION: setup Zakim for the 2nd face to face meeting [recorded in http://www.w3.org/2008/10/21-mediafrag-minutes.html#action02]
<trackbot> Sorry, couldn't find user - setup
Possible groups we will interact with: SYMM, SVG, HTML5, TAG, HTTP
Raphael: we need to agree on a
roadmap
... for creating editor's draft to have quickly feedback
... I would suggest to have a document that contains the Use
Cases + descriptions + sketch of the solutions we have
foreseen
... 2-way handshake, 4-way handshake, etc.
Silvia: I can create a new wiki page cleaning up the existing UCs
Guillaume: go back to the commutative property of a non functional syntax for expressing the syntax of the fragment
Jack: first investigate the '#'
scenario
... wait for the feedback of the other groups
... see if it works before considering the '?'
Everybody nodds and agrees with Jack
Silvia: in a way, we have defined how to do this communication server side with a '#'
Problems: gives a name to a fragment, how to communicate this to the server?
Silvia: URI#;name=test ... a
Range request: fragment test
... and then a 4-way handshake
Jack: do we envision that the UA will pass to the server what is after the hash through http headers?
Silvia: be carreful of the number
of new http headers we will create
... same http header but new headers
<nessy> http://www.iana.org/assignments/message-headers/perm-headers.html
Raphael: we consider the names
will be unique
... if there are multiple occurences of a name within the same
resource, then the UA might go to the first one
Jack: are these names UTF-8
encoded strings?
... can we have Japanese characters into these names?
... I want to do names ... and moreover, the syntax can cope
with any names which are allowable in other media formats
<nessy> quicktime example: http://peepcode.com/pages/quicktime-chapter-track
<nessy> jumping directly to chapters inside a quicktime chapter track
Jack: we might need some quoting
characters for the names
... if there is a quicktime addressing naming scheme, we need
to learn about
Silvia: will look for
<guillaume> "frame label" or "named anchors" for Flash http://noscope.com/journal/2004/04/named-anchors looking for example
Raphael: might be relevant if we want to explicitely create new resources
Yves: explains the latest
Internet Draft, with the HTTP Header Linking
... can be used to point to the parent resource
<scribe> ACTION: 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 http://www.w3.org/2008/10/21-mediafrag-minutes.html#action03]
<trackbot> 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].
<nessy> xpointer registry http://www.w3.org/2005/04/xpointer-schemes/
Jack: there is XPointer ... why is it still a WD since 2001?
<jackjansen> Xpointer spec: http://www.w3.org/TR/WD-xptr
Yves: I will ask Liam Quin what's going on
<Yves> http://www.w3.org/TR/xptr-framework/
<jackjansen> XPointer rec that google cannot find: http://www.w3.org/TR/2003/REC-xptr-framework-20030325/
Silvia: is XPointer only valid for XML documents?
Jack: yep, you're right
Raphael: XML is a structured document, this is not our case, should not copy the syntax
All: looking at http://www.ietf.org/rfc/rfc5147.txt
Silvia: should be added to my
current #<something> list
... '#<alpha>' [HTML], '#mf(...)' [MPEG-21], '#line=' or
'#char=' [RFC5147]
<jackjansen> One of the rfc5147 authors had an article at Hypertext 2005 on the subject, see http://dret.net/netdret/docs/wilde-ht2005-textfrag.pdf
<jackjansen> (refers to various people we know, too:-)
It is desirable that new and old proxies are able to cache fragments
Yves: a proxy does not
necessarily cache only resources
... should not be a problem with the solution we have
sketched
RTSP has a scheme for temporal URI ... but not for spatial URI
Silvia: we need to look at how they do that and potentially tell them to adopt our scheme
Davy: shoutcast should work over http
Guillaume: mms is huge
<davy> scribenick: davy
<jackjansen> Two papers on potential use cases for fragment (please don't share too widely just now, definitive versions later):
<jackjansen> http://homepages.cwi.nl/~jack/presentations/smilstate-for-rwab.pdf
<jackjansen> http://homepages.cwi.nl/~jack/presentations/mm08sharing-for-mf.pdf
raphael: the following should be in a UC & requirements doc
1. Addressing
3 dimensions: temporal, spatial, track
scribe: another dimension: named fragments
2. UA -> Server communication
scribe: only for http
... 2-way handshake and 4-way handshake
jack: use cases should be described before this
raphael: silvia will clean up the
wiki, at next teleconf, we will see what we have and take a
decision
... description of the use cases could be used as examples for
the addressing part
jack: should existing technologies be present in the doc?
raphael: that would be great, but
we will not have the time before the second f2f
... it is a todo
... smil, svg view, mpeg-21, temporal uri, ...
silvia: does SMIL have an addressing scheme? If not, it should not be addressed
guillaume: point is what does the technologies already do
jack: indeed, think functionality
raphael: URI solutions: XPointer,
RFC3986, Temporal URI, SVG view, MPEG-21 Part 17
... non-URI solutions: SMIL, SVG, MPEG-7
silvia: bottom-line is about fragment identification possibilities by comparing these technologies
jack: also add TimedText and CMML to the non-URI solutions
silvia: add HTML 5
raphael: add RTSP to point 2 (UA->Server communication)
<jun> PDF Open Parameters: http://partners.adobe.com/public/developer/en/acrobat/PDFOpenParameters.pdf
raphael: what about MMS and all the P2P protocols (e.g., subcast, pplive, ...)
silvia: find out if these specs support fragments
erik: are these P2P protocols open?
raphael: yes, I think so, they are mainly built by Chinese people
davy: is MMS not depricated?
<jackjansen> WMP11 does play MMS: http://www.tipandtrick.net/2008/solution-to-windows-media-player-11-wmp11-cannot-stream-and-play-mms-media-protocol-in-vista/
silvia: most protocols will have http or rtsp+udp as underlaying layer
raphael: in other groups: the
whole group is editor
... is this the solution we want?
silvia: we are a small group, so it would not be a big problem
raphael: editor as group, then no explicit names are given
jack: are editors the text writers or the contributers?
yves: there is also an acknowledgements section
raphael: I volunteer to write about point 2
jack: related technologies: we
should have a comparison based on point 1
... I will prepare a first version of point 3, erik & davy
prepare a second version
... is creating a movie which will be used as test case for the
technologies
guillaume: I also want to add some examples for existing technologies
raphael: could we have some dummy implementations for point 2
yves: I have a Java implementation of a web server
raphael: is there any existing Java cropping software?
silvia: there is one for mp3
yves: we would also need customization of the browser code
erik: all doc preparation on the wiki
guillaume: introduce 4. Syntax
raphael: adjourns the meeting