You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1829 lines
66 KiB
1829 lines
66 KiB
<!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 (vers 6 November 2007), see www.w3.org" />
|
|
|
|
<title>Media Fragments Working Group Teleconference -- 08 Mar
|
|
2010</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>08 Mar 2010</h2>
|
|
|
|
<p><a href=
|
|
'http://www.w3.org/2008/WebVideo/Fragments/wiki/FifthF2FAgenda'>Agenda</a></p>
|
|
|
|
<p>See also: <a href=
|
|
"http://www.w3.org/2010/03/08-mediafrag-irc">IRC log</a></p>
|
|
|
|
<h2><a name="attendees" id="attendees">Attendees</a></h2>
|
|
|
|
<div class="intro">
|
|
<dl>
|
|
<dt>Present</dt>
|
|
|
|
<dd>Davy, Erik, Yves, Frank_(observer), Jack, Raphael,
|
|
Silvia_(remote), Conrad_(remote), Michael_(remote),
|
|
Philip_(remote), Guillaume_(remote)</dd>
|
|
|
|
<dt>Regrets</dt>
|
|
|
|
<dt>Chair</dt>
|
|
|
|
<dd>Erik, Raphael</dd>
|
|
|
|
<dt>Scribe</dt>
|
|
|
|
<dd>raphael</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<h2>Contents</h2>
|
|
|
|
<ul>
|
|
<li>
|
|
<a href="#agenda">Topics</a>
|
|
|
|
<ol>
|
|
<li><a href="#item01">1. Administrative</a></li>
|
|
|
|
<li><a href="#item02">2. Media Fragments syntax</a></li>
|
|
|
|
<li><a href="#item03">3. Structure of the spec</a></li>
|
|
|
|
<li><a href="#item04">4. Multiple tracks</a></li>
|
|
|
|
<li><a href="#item05">5. Multiple but equivalent
|
|
Content-Range headers</a></li>
|
|
|
|
<li><a href="#item06">6. HTTP headers syntax</a></li>
|
|
|
|
<li><a href="#item07">6.1 Time dimensions</a></li>
|
|
|
|
<li><a href="#item08">6.2: Space dimension</a></li>
|
|
|
|
<li><a href="#item09">6.3: Track dimension</a></li>
|
|
|
|
<li><a href="#item10">6.4: ID dimension</a></li>
|
|
|
|
<li><a href="#item11">7. Wrap up</a></li>
|
|
|
|
<li><a href="#item12">8. AOB</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>trackbot</cite>> Date: 08 March
|
|
2010</p>
|
|
|
|
<p class='phone'>trackbot, start telecon</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Meeting: Media
|
|
Fragments Working Group Teleconference</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Date: 08 March
|
|
2010</p>
|
|
|
|
<h3 id="item01">1. Administrative</h3>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> scribenick:
|
|
raphael</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/FifthF2FAgenda">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/FifthF2FAgenda</a></p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Minor changes in the
|
|
agenda<br />
|
|
... tomorrow, we switch the 2 sessions on implementation report
|
|
and test cases<br />
|
|
... we will finish earlier, 15:30 PM most likely</p>
|
|
|
|
<p class='phone'>Erik announced the nice dinner we will have,
|
|
just to make jealous the remotes :-)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I'm having waffles
|
|
and ice cream for dinner right now :)</p>
|
|
|
|
<p class='phone'>OK, we will start, Conrad, Philip Michael,
|
|
phone when you can, asap :-)</p>
|
|
|
|
<h3 id="item02">2. Media Fragments syntax</h3>
|
|
|
|
<p class='phone'>First thing to consider: WG decision for
|
|
expressing wall-clock time code</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://www.ietf.org/rfc/rfc3339.txt">http://www.ietf.org/rfc/rfc3339.txt</a></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I am fine with
|
|
rfc3339</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> they all come from ISO</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> as reference</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> RFC3339 is just a recap,
|
|
but defined with ABNF</p>
|
|
|
|
<p class='phone'>RFC3339 abstract: "This document defines a
|
|
date and time format for use in Internet</p>
|
|
|
|
<p class='phone'>protocols that is a profile of the ISO 8601
|
|
standard for</p>
|
|
|
|
<p class='phone'>representation of dates and times using the
|
|
Gregorian calendar.</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> seems like a fine
|
|
reference to me</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> there is no diff than with
|
|
the ISO, except that it is defined with ABNF and we can copy
|
|
directly the def</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> i remind you of the
|
|
Resolution WG wiki page, <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions</a></p>
|
|
|
|
<p class='phone'><cite>Proposal:</cite> Use RFC3339 for
|
|
expressing time and date format (same than ISO8601 but
|
|
expressed in ABNF)</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> silvia, how
|
|
about aaa?</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> after femto
|
|
comes atto, iirc...</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> +1</p>
|
|
|
|
<p class='phone'>+1</p>
|
|
|
|
<p class='phone'><strong class='resolution'>RESOLUTION: we will
|
|
express wall-clock time code with RFC3339</strong></p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> +1</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Yves is editing the spec
|
|
_now_ so we save some actions :-)<br />
|
|
... the action is doing the changes in the spec</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> the aim is to have
|
|
FPWD at the end of tomorrow, so editing will be highly
|
|
necessary</p>
|
|
|
|
<p class='phone'>Second thing to consider: WG decision: having
|
|
quotes or not for name and id dimensions</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> can I point us to
|
|
<a href=
|
|
"http://www.w3.org/2002/09/wbs/42785/MFRAGSYNTAXSEGMENT/results">
|
|
http://www.w3.org/2002/09/wbs/42785/MFRAGSYNTAXSEGMENT/results</a></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> ups</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> <a href=
|
|
"http://www.w3.org/2002/09/wbs/42785/MFRAGSYNTAXQUOTE/results">http://www.w3.org/2002/09/wbs/42785/MFRAGSYNTAXQUOTE/results</a></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> we had the
|
|
discussion about quotes before</p>
|
|
|
|
<p class='phone'>Yes, this is what Jack was remining us
|
|
earlier</p>
|
|
|
|
<p class='phone'>See also the 3rd point in <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_URI_Syntax">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_URI_Syntax</a></p>
|
|
|
|
<p class='phone'>"The WG resolved on 2009/01/28 that single
|
|
quotes are optional to specify the value of the track and the
|
|
name dimensions but that double quotes are forbidden (see also
|
|
the poll results) "</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I still stand to
|
|
that decision</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> across all relevant
|
|
dimensions</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> relevant dimensions =
|
|
track and id ?</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> if we don't use quotes, is
|
|
there some strings we cannot specify ?<br />
|
|
... we thought there are some strings that require it, Philip
|
|
states it is not necessary<br />
|
|
... I tried toget some counter examples, I found just one:
|
|
YouTube, all the others work like Philip said</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> we use percent
|
|
encoding, quotes don't help</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Raphael: yes</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I agree with
|
|
foolip</p>
|
|
|
|
<p class='phone'>ACTIOn-150?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-150 -- Erik
|
|
Mannens to summarize the discussion on the quotes in a mail or
|
|
on the wiki -- due 2010-03-03 -- OPEN</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/150">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/150</a></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> but in the end, we
|
|
cannot prohibit people from using them, so I would simply
|
|
recommend against them in the spec</p>
|
|
|
|
<p class='phone'>Are the single quotes helping? Apparently not,
|
|
in this case, they have no value</p>
|
|
|
|
<p class='phone'>To silvia, Davy didn't get any issues at
|
|
all</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> using or not using
|
|
quotes?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> please don't make
|
|
them optional, that way implementations are stilled forced to
|
|
handle them</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> I agree: *if*
|
|
quotes don't help we shouldn't use them.</p>
|
|
|
|
<p class='phone'>To silvia: using it</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I agree with Philip and
|
|
Jack, if they are not necessary, then we should NOT use
|
|
them</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> so, Davy used quotes
|
|
- did he use percent-encoding in his implementation? or were
|
|
the quotes necessary because he didn't use
|
|
percent-encoding?</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> Silvia: indeed, we did
|
|
not use percent-encoding because of the quotes</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> so the question is
|
|
between percent-encoding or single quotes?</p>
|
|
|
|
<p class='phone'><cite>Erik:</cite> I prepared a word document
|
|
for my action-150, not online yet</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> btw: 7.3. Back-End
|
|
Transcoding in <a href=
|
|
"http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>
|
|
also talks about percent encoding in name-value pairs (here for
|
|
query)</p>
|
|
|
|
<p class='phone'>Erik listed 4 problems that will be list in
|
|
the minutes</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> Raphael raised
|
|
possible problems on this issue on <a href=
|
|
"http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0002.html">
|
|
http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0002.html</a></p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> those aren't
|
|
problems, those are limitations already listed in the spec</p>
|
|
|
|
<p class='phone'>For the 3rd limitations, the "+" character, we
|
|
should warn that the + should be %-encoded</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> by using quotes we
|
|
would be adding a fith point</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> or are we not
|
|
discussion percent-encoding vs quotes any longer?</p>
|
|
|
|
<p class='phone'>Philip, yes, we are still discussing
|
|
percent-encoding vs quotes</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> though the discussion is
|
|
going in various ways</p>
|
|
|
|
<p class='irc'><<cite>guillaume</cite>> examples?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> + only needs to be
|
|
percent-encoded if we make + be replaced by a space.</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> no, because of the
|
|
duality of + used in the past to encode ' '</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> we are back to the
|
|
original point of discussion</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> '+' is a reserved
|
|
character in rfc3986 (sub-delims)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I think that should
|
|
be borne by those who use PHP and friends to parse MF, despite
|
|
the problems</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I would say, yes, take out
|
|
the quotes, but perhaps put a note in the spec where we ask
|
|
specifically some feedback on this issue</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> ok, so a URL with +
|
|
unescaped is invalid?</p>
|
|
|
|
<p class='irc'><<cite>guillaume</cite>> what are current
|
|
and future best practice out there : less readable % encoded OR
|
|
more structured quote based?</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> between quotes, the
|
|
subdelim are still valid</p>
|
|
|
|
<p class='phone'>Guillaume, read the long thread of dicussion
|
|
we had :-)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> + is a sub-delim
|
|
according to <a href=
|
|
"http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>
|
|
and as such already needs to be %encoded</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> foolip: not invalid,
|
|
but interop issues</p>
|
|
|
|
<p class='phone'>Philip, can you phone in for 15 minutes ?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> raphael: can I use
|
|
Skype?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I have no real
|
|
phone</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it really isn't a
|
|
problem - it's what the server makes of it that counts - and
|
|
YouTube accepts + in lieu of ' ', but that doesn't mean others
|
|
do</p>
|
|
|
|
<p class='phone'>Yes PHilip</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> to Philip, Silvia, we
|
|
are resuming the discussion, having single quotes or not.
|
|
Single quotes have sometime values in the sense that some track
|
|
names will not be %-encoded</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> the spec says that
|
|
you have to %encode the content values</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> if I read the RFC 3986,
|
|
section 7.2, it says that sub-delim MUST be %-encoded if you
|
|
want them to be treated as data</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> silvia; yes, that is
|
|
right, encode values</p>
|
|
|
|
<p class='phone'><cite>Erik:</cite> is that the case also for
|
|
the ' ' (space) ?<br />
|
|
... so why you would like to put quotes, if the browser doesn't
|
|
transform the space into %20 ?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> well, space is not
|
|
part of the delimiters, but section 2.1 explicitly talks about
|
|
%20</p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> any special character
|
|
which is not part of the reserved set is transformed into a
|
|
%-encoding version</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> this is what you said
|
|
Philip?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> yes</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> transformed by the
|
|
browser</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> with the addition
|
|
that I haven't tested all possible input</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> unreserved = ALPHA /
|
|
DIGIT / "-" / "." / "_" / "~"</p>
|
|
|
|
<p class='phone'>Jack summary: we have 3 sets of characters</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> "The only exception
|
|
is for</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> percent-encoded
|
|
octets corresponding to characters in the unreserved</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> set, which can be
|
|
decoded at any time."</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> unreserved: there are
|
|
never been encoded (if you do it, you type too much)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> so, everything that
|
|
is not in the unreserved set has to be encoded</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> reserved: delim and sub
|
|
delim, MUST be %-encoded</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> according to
|
|
<a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a></p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> the rest ... which is
|
|
just illegal (including the space)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> or better still, in
|
|
2.5:</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> "When a new URI
|
|
scheme defines a component that represents textual</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> data consisting of
|
|
characters from the Universal Character Set [UCS],</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> the data should
|
|
first be encoded as octets according to the UTF-8</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> character encoding
|
|
[STD63]; then only those octets that do not</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> correspond to
|
|
characters in the unreserved set should be percent-</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> encoded."</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I think I'm convinced
|
|
that the quotes are therefore useless</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I am too :)</p>
|
|
|
|
<p class='phone'>Jack is too</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Whatever you
|
|
say, Chairman</p>
|
|
|
|
<p class='phone'><cite>Proposal:</cite> the WG does NOT
|
|
consider that single quote is a special character. It will not
|
|
be used by the Media Fragment syntax. It contradicts a earlier
|
|
resolution from the group, but the group acquired a better
|
|
knowledge of the role of the quotes in a URI since.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> +1</p>
|
|
|
|
<p class='phone'>+1</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> =</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> ?</p>
|
|
|
|
<p class='irc'><<cite>guillaume</cite>> ?</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Or should we
|
|
vote %2b1?</p>
|
|
|
|
<p class='irc'><<cite>guillaume</cite>> %2b1 then</p>
|
|
|
|
<p class='phone'><strong class='resolution'>RESOLUTION: the
|
|
media fragment syntax does not treat the single quote as a
|
|
special character. Values for the track and id dimensions
|
|
should be percent-encoded when necessary</strong></p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> 3b2 otoh is an
|
|
old unix machine...</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> note that even the
|
|
names can be percent encoded, even if it's ugly</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> we should clarify and put a
|
|
strong statement in the spec that the number of characters we
|
|
can use non-%-encoded is very limited and point to them the
|
|
RFC3986 for that. Most of the characters should be
|
|
%-encoded</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I mean in t=1, t
|
|
could be percent-encoded</p>
|
|
|
|
<p class='phone'>Yes Philip, but for the unreserved characters,
|
|
you're typing too much by escapting them</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> unless we want to
|
|
decide otherwise</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> fine, as long as we
|
|
agree it's valid</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> t is in the
|
|
unreserved set and thus rfc3986 recommends not encoding it</p>
|
|
|
|
<p class='irc'><<cite>fdenoual</cite>> Point to RFC 3986
|
|
instead of RFC3986 in the above clarification</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Silvia, yes, but it also
|
|
says that it does not matter if you encode it</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 6.2.2.2.
|
|
Percent-Encoding Normalization <- explicitly talks about not
|
|
encoding them</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> yes, I agree</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> two remaining
|
|
problems<br />
|
|
... a) We should put somewhere in the spec a warning to the
|
|
reader that most of the characters will be escaped, since the
|
|
unreserved set of characters that do not need %-encoding is
|
|
very limited<br />
|
|
... b) Should we keep the section 5.1.1 like that? (<a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-name-value-components)">http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-name-value-components)</a></p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I'm very against</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> I'm very agains too</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> against which?</p>
|
|
|
|
<p class='irc'><<cite>fdenoual</cite>> Section 5.1.1</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Against using
|
|
pseudo-code fragements in normative text, as in 5.1.1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I do not think we
|
|
need to repeat what rfc3986 says about percent-encoding, so I
|
|
am against a)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> a) seems
|
|
redundant</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> Michael: I
|
|
gotta drop out now for an hour or so - will join you likely
|
|
after the lunch break (hope I can make it earlier)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> b) otoh clarifies a
|
|
lot - I don't mind the pseudo-code</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> why are you against
|
|
it?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it clarifies what
|
|
rfc3986 doesn't specify, but refers to a lot: what are
|
|
name-value pairs in queries (and for us in fragments)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> if someone can
|
|
define processing of name-value pairs by some other method,
|
|
fine</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> but I'm definitely
|
|
against removing normative text without replacing it or leaving
|
|
it "implicit" (i.e. undefined)</p>
|
|
|
|
<p class='phone'>OK, back to a), we don't want to repeat but
|
|
add some examples to clarify</p>
|
|
|
|
<p class='phone'>Yves is editing live the spec, to remove the
|
|
production rules with the quotes</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> and add some examples in
|
|
section 4.2.5<br />
|
|
... examples of a temporal fragment with a + that is encoded, a
|
|
track fragment with a '&' that is encoded, etc.<br />
|
|
... the idea is to warn once more the reader that most of the
|
|
chacacters need to be encoded, it seems useful since we had
|
|
some much dicussion about it</p>
|
|
|
|
<p class='phone'><cite>now:</cite> b)</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I have written an email why
|
|
I think the pseudo-code is not good in the spec</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> section 4.2.3 has
|
|
quotes in examles</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> and 4.2.4</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> there is a problem with
|
|
the section 5.1.1</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> the pseudo code is fuzzy,
|
|
less valuable than written in a declarative language<br />
|
|
... the pseudo code will always make things less clear</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> mediasegment =
|
|
namesegment / axissegment</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> axissegment = (
|
|
<a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#timesegment">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#timesegment</a>
|
|
/ <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#spacesegment">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#spacesegment</a>
|
|
/ <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#tracksegment">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#tracksegment</a>
|
|
)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> *( "&" (
|
|
<a href="http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#timesegment">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#timesegment</a>
|
|
/ <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#spacesegment">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#spacesegment</a>
|
|
/ <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#tracksegment">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#tracksegment</a>
|
|
)</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I propose to replace this
|
|
pseudo algorithm with just a few sentences that state we must
|
|
first identify the key and values<br />
|
|
... follow what RFC is saying</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> there are things you
|
|
cannot write in ABNF<br />
|
|
... I prefer the text that Philip wrote</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> the non agreement seems
|
|
to be between specifying things in a declarative language vs
|
|
procedural language</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> you can rephrase this
|
|
section, but I think we should NOT remove it</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I would like to
|
|
speak</p>
|
|
|
|
<p class='phone'>Yes, Philip, 2 sec</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> adding examples would
|
|
be good</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> always helpful to
|
|
clarify things for both programmers and users</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> say "as transcribed in
|
|
pseudo-code" instead of "as an example"</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> I propose to write the ABNF
|
|
declarative language, and then, "as transcribed in pseudo code"
|
|
and put the text of Philip^</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> this is the only
|
|
place that defines how to split name-value pairs, it is not
|
|
clarifying</p>
|
|
|
|
<p class='phone'>the spec can be restructured</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> you'll notice that
|
|
there's no ABNF for &-=-separated lists</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I wouldn't move it
|
|
to another location - it's in the right place</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Philip,
|
|
splitting name/value pairs is described in the abnf...</p>
|
|
|
|
<p class='phone'>See <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#fragment-structure">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#fragment-structure</a></p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Yep, very first
|
|
2 productions</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> axissegment = (
|
|
timesegment / spacesegment / tracksegment )</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> *( "&" (
|
|
timesegment / spacesegment / tracksegment )</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I removed that,
|
|
someone put it back it seems</p>
|
|
|
|
<p class='phone'>:-)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> it doesn't make any
|
|
sense to have both</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I think it does,
|
|
because that rule is rather unclear</p>
|
|
|
|
<p class='phone'>OK, we make a smoking coffee break</p>
|
|
|
|
<p class='phone'>we come back after</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> silvia, which
|
|
rule is unclear, and why?</p>
|
|
|
|
<p class='phone'>15 minutes break</p>
|
|
|
|
<p class='irc'><<cite>guillaume</cite>> ok</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> the rule in 4.1 is
|
|
missing the percent-encoding</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> no, it's included in
|
|
utf8string definition</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> the axissegment
|
|
makes no sense, timesegment and others should be matched
|
|
*after* percent-decoding</p>
|
|
|
|
<p class='phone'>We do the break ... and I will phrase after my
|
|
proposal of restructuring ... just wait</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> unless we have ABNF
|
|
for percent-encoding + UTF-8 then there cannot be a complete
|
|
ABNF at the URI level</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> there are two
|
|
levels</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> and the way it is
|
|
now, the dimension value is not %encoded</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> ok, I'll be back in
|
|
15</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> yes, I removed the
|
|
parts that didn't make sense, now that they are back the spec
|
|
is just nonsense</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Philip, that's
|
|
about which terminals you have. Parsing vs. Lexing.</p>
|
|
|
|
<p class='phone'>close ACTION-150</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-150
|
|
Summarize the discussion on the quotes in a mail or on the wiki
|
|
closed</p>
|
|
|
|
<p class='phone'>close ACTION-143</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-143 Move
|
|
5.1.5 into a new section closed</p>
|
|
|
|
<p class='phone'>close ACTION-144</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-144 Move
|
|
the section 5.1.1 to the top closed</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> jackjansen: ? What
|
|
does that mean, in practice?</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> ok, time to go
|
|
home, zakim seems to think... :-)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Yves: TCP/IP is not
|
|
specified in declarative syntax, but has plenty of procedural
|
|
sections in it, <a href=
|
|
"http://www.ietf.org/rfc/rfc793.txt">http://www.ietf.org/rfc/rfc793.txt</a></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> e.g.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> SYN-RECEIVED
|
|
STATE</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> If SND.UNA =<
|
|
SEG.ACK =< SND.NXT then enter ESTABLISHED state</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> and continue
|
|
processing.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> If the segment
|
|
acknowledgment is not acceptable, form a</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> reset segment,</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>>
|
|
<SEQ=SEG.ACK><CTL=RST></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> and send it.</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> silvia, as I said
|
|
earlier, I am ok to have both</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> it's kind of
|
|
pointless to have this discussion without an alternative
|
|
available for evaluation</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> the most important
|
|
thing is that it is actually defined how to process name-value
|
|
pairs</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Yves, I was just
|
|
curious about your statement and investigated :)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I agree, I think we
|
|
should have both</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> the ABNF doesn't,
|
|
but by having it the spec is simply self-contradictory about
|
|
how to handle invalid name/value pairs</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it will just be a
|
|
challenge to make sure they actually express the same and don't
|
|
contradict each other</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I'd prefer to just
|
|
have one representation, for sanity</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> the two current ones
|
|
don't express the same thing, at all</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> so we need to fix
|
|
that</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> indeed</p>
|
|
|
|
<h3 id="item03">3. Structure of the spec</h3>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> from a high level view,
|
|
I think we have various bits wrongly placed<br />
|
|
... Section 4 is about Media Fragment URI syntax<br />
|
|
... but Section 5 is about both how to process this syntax and
|
|
how the protocol is working, soon with the headers syntax<br />
|
|
... I suggest that everything about the URI syntax should go in
|
|
Section 4, so also the bits in 5.1.1 and 5.1.2<br />
|
|
... and the section 5 should be only about protocol and headers
|
|
syntax<br />
|
|
... and I have also problems with the section 5.1.3</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> that refers only to
|
|
section 5.1 ?</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> if the section 5.1.3 is
|
|
mainly about how to render a fragment in the UA, perhaps put a
|
|
section 5.4 for that</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I agree, 5.1.3 is a
|
|
bit of a headache</p>
|
|
|
|
<p class='phone'>what do you mean: "that refers only to section
|
|
5.1 ?" ?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I think the last
|
|
paragraph in 5.1.3 needs its own section, but the rest
|
|
doesn't</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> when I said "that
|
|
refers only to section 5.1" I meant: your problems with syntax
|
|
in section 5 are actually only with section 5.1, right?</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> following Frank suggestion,
|
|
I would suggest having 4. Syntax; 5. Protocol; 6. Display</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> not only silvia but
|
|
mainly with 5.1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I don't see any new
|
|
syntax anywhere else</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> no processing?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> and move 6. Error
|
|
handling to 7 ?</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Philip, 5. Protocol
|
|
means processing the fragments and generate the headers</p>
|
|
|
|
<p class='phone'>yes silvia</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> please no error
|
|
handling :(</p>
|
|
|
|
<p class='phone'>Silvia, new syntax elements soon to be
|
|
introduced with ABNF versions of HTTP headers and HTTP
|
|
responses</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> it's just
|
|
"handling"</p>
|
|
|
|
<p class='phone'>Why Philip ?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> you handle errors
|
|
and non-errors in the same way</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> those should stay
|
|
with the protocol</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> it's much clearer to
|
|
put it in the same section</p>
|
|
|
|
<p class='phone'>I don't understand silvia, what should stay
|
|
with the protocol?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> they are, but
|
|
finding a better name for the section is difficult - got a
|
|
proposal?</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> silvia, how
|
|
about "implementation guidelines"?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> the syntax
|
|
specification of the HTTP headers need to say with the
|
|
protocol</p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> you want to have the
|
|
errors in the same section than the protocol?</p>
|
|
|
|
<p class='phone'>this is what I said Silvia</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> not guidelines,
|
|
normative, absolute rules</p>
|
|
|
|
<p class='phone'>status of section (normative vs not) is
|
|
independent</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it's not actually
|
|
about implementation guidelines - it's about how to process
|
|
actual values</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> maybe it's the
|
|
processing section that Philip is missing</p>
|
|
|
|
<p class='phone'>can you phone in Silvia ... too many
|
|
misunderstandings</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> raphael: good - just
|
|
wanted to make sure case it's syntax, too :)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> just two different
|
|
communication threads :)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> no no no</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I would like to
|
|
speak :)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> raphael: no, there's
|
|
no phone around</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> ok, I'll just write
|
|
on IRC</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> my proposal is section 4
|
|
= media fragment URI syntax (including the current sections
|
|
5.1.1 and 5.1.2)<br />
|
|
... section 5 = protocol handling, ABNF syntax of the HTTP
|
|
headers, communication between servers and UA (current sections
|
|
5.2 and 5.3)<br />
|
|
... section 6 = display (current section 5.1.3)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I like semantics</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> section 7 = semantics +
|
|
error handdling</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I'd like to explain
|
|
the different levels here</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> lowest level: URI
|
|
fragment component (or URI query component)</p>
|
|
|
|
<p class='phone'>Jack propose to switch sections 6 and 7</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> semantics first, then
|
|
display / render</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> the syntax of this
|
|
is *arbitrary* &-=-separated strings</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I agree</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> the result of
|
|
parsing this is a list of name-values</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> media fragments is
|
|
modelled on top of this, not on the URI string</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> in my versions</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> fuly agree with
|
|
philip</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> fully</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> so, the ABNF or
|
|
whatever must reflect this</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> we can't say that
|
|
the fragment component is composed from timesegment or
|
|
whatever</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> we all agree with you
|
|
Philip, and suggest to add this in Section 4</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> i.e. the ABNF in 4.1
|
|
must be changed, or removed</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Philip, why?</p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> we don't understand this:
|
|
" we can't say that the fragment component is composed from
|
|
timesegment or whatever"</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> jackjansen: because
|
|
timeprefix and timeparam should be matched after splitting</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> and after
|
|
percent-decoding and UTF8-decoding</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> i.e. they aren't on
|
|
the same "level"</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> That's because
|
|
urls are our main language.</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> if c++ was our
|
|
main language it would be datastructures.</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> the current *segment
|
|
syntaxes don't make this distinction</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> No, because it's
|
|
semantics, not syntax.</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Same would be
|
|
true for c++ datastructure declarations...</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> are you missing the
|
|
"timeprefix = timeparam" in 4.1 ?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> (and same for all
|
|
other examples, saying that it's foo = bar)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I think the
|
|
difference comes from the fact that Philip is looking at the
|
|
URL from a parsing POV and Yves from a production POV</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> the grammar says that
|
|
it's foo = bar then bar is percent encoded (see def of
|
|
utf8string)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> so the grammar already
|
|
says that you split, then decode</p>
|
|
|
|
<p class='irc'><<cite>fdenoual</cite>> Is is possible to
|
|
express sthg like: segment = *(segmentname=segmentvalue)
|
|
?...</p>
|
|
|
|
<p class='irc'><<cite>fdenoual</cite>> ... and then
|
|
express segmentname and segmentvalue</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I think the
|
|
difference is that we need to keep the option open to have
|
|
other name-value pairs in the URL, too</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> we cannot just
|
|
restrict it to the ones we define</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> if I understand Philip
|
|
correctly, the structuring of the ABNF is not the one that
|
|
implementers will follow, and that will hinder future
|
|
extensibility</p>
|
|
|
|
<p class='phone'>is that correct?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> yes</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> so jackjansen is
|
|
suggesting that implementors should ignore the spec and accept
|
|
other input than the ABNF allows?</p>
|
|
|
|
<p class='phone'>no</p>
|
|
|
|
<p class='irc'><<cite>fdenoual</cite>> I think Philip
|
|
would like to see translated "fragment identifier consists of a
|
|
list of name/value pairs" into ABNF at top-level.</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> there should be no
|
|
spirit, just hard, unambiguous requirements</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> we should specify
|
|
exactly what UAs should accept</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> otherwise we won't
|
|
have interop</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Philip, we
|
|
cannot have requirements for extensions.</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I can hear</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> jjust not talk</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> ok</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> there is no
|
|
requirement for extensions, but we have to specify the document
|
|
so we allow them</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> we can be very sure
|
|
that we want to add things like foo=bar, no?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> indeed, we need to
|
|
have the spec written such that any name-value pair is
|
|
parsed</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> because the syntax
|
|
doesn't allow it</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> and only the ones
|
|
that are relevant to us will be specified in the document</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> unless we want
|
|
implementors to guess what we meant</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> right now the ABNF
|
|
spec doesn't allow other name-value pairs</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> yes, jackjansen is
|
|
on the right track</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I agree :)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it's what the
|
|
pseudocode describes, but not the ABNF right now</p>
|
|
|
|
<p class='phone'>ok, we start to understand *ad* agree</p>
|
|
|
|
<p class='phone'>changes need to be made in Section 4</p>
|
|
|
|
<p class='phone'>I would suggest to make these changes during
|
|
lunch break</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> yes, what jackjansen
|
|
is saying is exactly what I intended when making the processing
|
|
section for name-value strings</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> and the %encoding /
|
|
decoding needs to happen in the URI part, not in the name-value
|
|
spec part</p>
|
|
|
|
<p class='phone'>and we are all enthousiastic, thanks
|
|
Philip</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> excellent :))</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> indeed, it's
|
|
important that implementations aren't required to understand
|
|
all current and future possible syntax :)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> thanks, I will drop
|
|
out now to have dinner</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I haven't been that
|
|
involved with multiple tracks anyway</p>
|
|
|
|
<p class='phone'><cite>Conlusion:</cite> Yves will work at the
|
|
beginning of the morning on the reshuffle of the section 4</p>
|
|
|
|
<h3 id="item04">4. Multiple tracks</h3>
|
|
|
|
<p class='phone'>Can we have multiple tracks at all?</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> we said that multiple ids
|
|
or multiple parallel tracks is too complicated</p>
|
|
|
|
<p class='irc'><<cite>fdenoual</cite>> ABNF definition of
|
|
axissegment enables combination of tracks</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> we talked about multiple
|
|
occurrence of t=x, and I agree this is an error<br />
|
|
... we haven't dicussed this for tracks</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> exception for tracks?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> there should only be
|
|
one track dimension in a URL, but it can have a semicolon
|
|
separated list of tracks</p>
|
|
|
|
<p class='phone'>Yes, this is what Jack said</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> should we have a
|
|
resolution for that? and check afterwards, we can actually
|
|
generate good headers with that :-)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> ; is a sub-delimiter
|
|
in URI, so we can use it</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> yes, but we need to make
|
|
sure that at the semantics level, t=10,20;30,40 is
|
|
incorrect</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it's already
|
|
syntactically incorrect</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> with multiple tracks
|
|
we are only changing the production rule of the value of the
|
|
track segment</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> not all values of
|
|
all segments</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> So assume
|
|
track=audio;subtitle is correct. Now how about
|
|
id=section1;section2 ?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 4.2.3</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> tracksegment =
|
|
trackprefix "=" trackparam</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> trackprefix =
|
|
%x74.72.61.63.6B ; "track"</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> trackparam =
|
|
utf8string</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> change to</p>
|
|
|
|
<p class='phone'>Yes, silvia, that is easy</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> tracksegment =
|
|
trackprefix "=" trackparam [; trackparam]*</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> or something similar
|
|
:)</p>
|
|
|
|
<p class='phone'>This is what Yves was writing on the board</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> changes will happen
|
|
during your sleep</p>
|
|
|
|
<p class='phone'><cite>Proposal:</cite> the media fragment URI
|
|
will allow multiple values for the track dimension, separated
|
|
by a semi-colon</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> =</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> +1;</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> +1</p>
|
|
|
|
<p class='phone'><strong class='resolution'>RESOLUTION: the
|
|
media fragment URI will allow multiple values for the track
|
|
dimension, separated by a semi-colon, assuming we are
|
|
considering only one temporal range</strong></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> the semantics are an
|
|
enumeration of the chosen tracks, right?</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> corect</p>
|
|
|
|
<h3 id="item05">5. Multiple but equivalent Content-Range
|
|
headers</h3>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> I'm happy to have a new
|
|
header called Content-Range-Equivalent</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 5.2.2</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> reading the editorial
|
|
note at the end of the section 5.2.2<br />
|
|
... Conrad used to named it Fragment, and we call it
|
|
Content-Range-Equivalent<br />
|
|
... the purpose is to do the mapping between equivalent ranges
|
|
expressed in different units</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> if we need to
|
|
enumerate tracks, we may need to quote them to isolate possible
|
|
occurences of the delimiter...</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> e.g. between seconds and
|
|
bytes</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> ok, we will work on the
|
|
ABNF syntax of the headers this afternoon</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> in the headers, if there
|
|
are multiple tracks, we might need quotes<br />
|
|
... I need to check</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://tools.ietf.org/html/rfc2047">http://tools.ietf.org/html/rfc2047</a></p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> ok, then i suggest to use
|
|
this rfc also</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Silvia, could
|
|
you follow that?</p>
|
|
|
|
<p class='phone'>Not really Silvia, look at RFC 2047, section
|
|
4.2</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> are you not mixing queries
|
|
and fragments? queries are percent-encoded</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> to me, the header
|
|
name "Content-Range-Equivalent" seems to imply a contiguous
|
|
subrange of the resource, whereas a selection (intersection) of
|
|
tracks is something more complex</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> foo=bar</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> in the uri:
|
|
foo=b%XXr</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> in the header:</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> Toto: foo=bar</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> or</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> "syntax of
|
|
name-value pairs", independent of anything else in the spec</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Toto: foo=b%XXr</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> foolip, yes</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> URI parsing =>
|
|
name=value pairs => encode in HTTP</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I'd put a step
|
|
between name-value pairs and HTTP</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I think we should have
|
|
this in a diagram, re: URI parsing => name=value pairs =>
|
|
encode in HTTP</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> which is
|
|
interpreting the list of name-value pairs that resulted from
|
|
the first step</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> URI parsing (percent
|
|
decoding) => name=value pairs => (rfc2047encoding)
|
|
HTTP</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> I wonder why the percent
|
|
decoding should happen at all on client side<br />
|
|
... ... but perhaps clients are already doing that already</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://www.example.com/foo#t=%34">http://www.example.com/foo#t=%34</a></p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> a client must decode
|
|
that</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> if my URL is file:// the
|
|
client is the only one who can decode</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> OK, I understand the
|
|
argument, and I agree that clients might also decode the
|
|
fragment part of the url</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I would propose that
|
|
somewhere in the document we have a figure that represents the
|
|
following steps: URI parsing (percent decoding) =>
|
|
name=value pairs => (rfc2047encoding) HTTP</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> should be the new
|
|
first part of section 4, which has the general uri media
|
|
fragment parsing in it</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> ok, I will have to
|
|
leave now too, it's way after work hours</p>
|
|
|
|
<p class='phone'>thanks philip</p>
|
|
|
|
<p class='phone'>we will make a summary tonight ... talk to you
|
|
tomorrow morning</p>
|
|
|
|
<p class='phone'>it would be great if you would be able to
|
|
phone for limited period of time when necessary</p>
|
|
|
|
<p class='phone'>do you know you can open a skype out account
|
|
and phone on copper line ? it's very cheap</p>
|
|
|
|
<p class='phone'>there is also free voip service ... like one
|
|
hour free phone per day</p>
|
|
|
|
<p class='phone'>voipbuster I think does that</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I've had a look at
|
|
it, I'll try to arrange something</p>
|
|
|
|
<h3 id="item06">6. HTTP headers syntax</h3>
|
|
|
|
<p class='phone'>close ACTION-141</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-141 Add a
|
|
paragraph in the section 5.2.1 that further clarify the role of
|
|
the UA for rendering a media fragment closed</p>
|
|
|
|
<p class='phone'>ACTION-132?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-132 --
|
|
Philip Jägenstedt to send to the mailing list a description of
|
|
a new issue to be discussed (dealing with decimal for
|
|
specifying time?) -- due 2010-02-03 -- OPEN</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/132">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/132</a></p>
|
|
|
|
<p class='phone'>Philip, do you remember this action?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> no, was that
|
|
something spawned in another teleconf?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> in any case it had
|
|
to do with the NPT syntax and I did send such a mail and it has
|
|
since been changed</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> so close the action
|
|
as done and all is good</p>
|
|
|
|
<p class='phone'>ok</p>
|
|
|
|
<p class='phone'>Philip, when the action was given: <a href=
|
|
"http://www.w3.org/2010/01/27-mediafrag-minutes.html#item04">http://www.w3.org/2010/01/27-mediafrag-minutes.html#item04</a></p>
|
|
|
|
<p class='phone'>are you sure we can close it?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> yes, the current
|
|
format allows a decimal point with no trailing digits</p>
|
|
|
|
<p class='phone'>close ACTION-132</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-132 Send to
|
|
the mailing list a description of a new issue to be discussed
|
|
(dealing with decimal for specifying time?) closed</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> ok, we resume, I suggest
|
|
we work on the ABNF syntax of the HTTP headers for the time,
|
|
space and track dimensions this afternoon<br />
|
|
... we will work on board</p>
|
|
|
|
<p class='phone'>Conrad, Philip or Michael, do you plan to
|
|
phone in ?</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> ok, ie. in 11min
|
|
time?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-09#section-5.4.1">
|
|
http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-09#section-5.4.1</a></p>
|
|
|
|
<p class='phone'>Reading all <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/</a>,
|
|
new version 1.62</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> as a user, I'm now
|
|
interested in sections 4 and 6 (what to type and what to
|
|
expect)<br />
|
|
... as a client/server implementer, I'm interested in section
|
|
5<br />
|
|
... I'm wondering about the sub-structuring of the section
|
|
5<br />
|
|
... if I want to implement for file:// or rtsp://, should I
|
|
read that?</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> no objection on the
|
|
re-structuring<br />
|
|
... we go though each dimensions now and specify the headers
|
|
syntax</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> the re-structuring
|
|
looks great</p>
|
|
|
|
<h3 id="item07">6.1 Time dimensions</h3>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> the range request is
|
|
expressed in bytes ... no problem, normally range request as
|
|
specified in HTTP<br />
|
|
... the range request is expressed in another unit ... see also
|
|
ed note from Silvia at <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-Server-mapped">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-Server-mapped</a></p>
|
|
|
|
<p class='phone'>What we have already: <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers</a></p>
|
|
|
|
<p class='phone'>I will scribe Conrad</p>
|
|
|
|
<p class='phone'>We agree on: Range: <dimension> ':'
|
|
<unit> '=' <start-pos> - <end-pos></p>
|
|
|
|
<p class='phone'>We are discussing the Content-Range
|
|
response</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> the proposal is to start
|
|
from: Content-Range: <dimension> ':' <unit> ' '
|
|
<real-start-pos> '-' <real-end-pos> '/'
|
|
(<instance-length> / "*" )</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> ok sounds fair</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> and define
|
|
<instance-length> depending on the unit</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> i propose to use
|
|
Range-Equivalent and Content-Range-Equivalent for non-byte
|
|
units</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> sorry, the
|
|
dimension<br />
|
|
... if the dimension is time, then, Jack proposes that
|
|
instance-length is originalStart-originalEnd</p>
|
|
|
|
<p class='phone'><cite>Example:</cite> Content-Range: t:npt
|
|
100-120/0-3600</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> so that existing
|
|
byte range caching can continue to work, for transport of
|
|
temporal or spatial responses</p>
|
|
|
|
<p class='phone'>Conrad, existing cache will still continue to
|
|
work by overriding the Content-Range and Range headers</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> they will ust not cache
|
|
it<br />
|
|
... except if caches understand our syntax</p>
|
|
|
|
<p class='phone'>so why creating neww headers? rather than
|
|
overriding existing ones?</p>
|
|
|
|
<p class='phone'>s/neww/new</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> of course it is true
|
|
that the existing caches will not catch fire or anything</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> :)</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> i think it would be
|
|
useful to cache bytes 1000-2000 of the resource which is time
|
|
2min-3min</p>
|
|
|
|
<p class='phone'>we will come to that later on</p>
|
|
|
|
<p class='phone'>with for example the Content-Range-Equivalent
|
|
header ... or whatever</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> a cache can be told
|
|
to vary on Content-Range-Equivalent</p>
|
|
|
|
<p class='phone'>Issue is what is the mime type of the HTTP
|
|
response</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> the origin server
|
|
can respond with the full resource, Content-Range-Equivalent:
|
|
npt 10-20s or whatever; a proxy can cache that, and when a new
|
|
request comes through it, it can provide byte ranges of that
|
|
response</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> another use case is
|
|
a user agent that wants to request a media stream in chunks of
|
|
say 10kB at a time</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> even if the resource
|
|
being requested is a time range, it might first do:</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> Range-Equivalent:
|
|
npt 10min-20min</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> Range: bytes
|
|
0-10000</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> then next do:</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> Range-Equivalent:
|
|
npt 10min-20min</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> Range: bytes
|
|
10000-20000</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> etc.</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> the Range-Equivalent
|
|
specifies the representation that is wanted</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> but the Range is a
|
|
means of transporting that</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I'm the only who follow
|
|
what you write :-) ... but your Range-Equivalent is missleading
|
|
because it is NOT equivalent to the Range</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> so both these
|
|
requests invoke the response header Content-Range-Equivalent:
|
|
npt 10min-20min</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> (excuse the min
|
|
specifier ;-)</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> raphael, ok, so call
|
|
it something other than Range-Equivalent :)</p>
|
|
|
|
<p class='phone'>Conrad, there are 3 cases defined in sections
|
|
5.2.1, 5.2.2 and 5.3.3</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> we are now talking about
|
|
5.2.2</p>
|
|
|
|
<p class='phone'>ok Conrad,</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> ( *LWS element *( *LWS
|
|
"," *LWS element ))</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> can be shown as</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> 1#element</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> 2.1 Augmented BNF</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> (of RFC2616)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> token = 1*<any CHAR
|
|
except CTLs or separators></p><a name="action01" id=
|
|
"action01"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Yves to modify the production rule for
|
|
the track dimension in order to allow multiple comma separated
|
|
values [recorded in <a href=
|
|
"http://www.w3.org/2010/03/08-mediafrag-minutes.html#action01">http://www.w3.org/2010/03/08-mediafrag-minutes.html#action01</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-151
|
|
- Modify the production rule for the track dimension in order
|
|
to allow multiple comma separated values [on Yves Lafon - due
|
|
2010-03-15].</p>
|
|
|
|
<p class='phone'>Multitrack API: <a href=
|
|
"http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI">http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI</a></p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-09#section-3.2">
|
|
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-09#section-3.2</a></p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> for the time dimension,
|
|
we edit live the http headers and response at <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers</a></p>
|
|
|
|
<h3 id="item08">6.2: Space dimension</h3>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> The WG considers that
|
|
extracting a region from an image should be done with the query
|
|
parameter when transcoding is required (most of the cases).
|
|
From the specification point of view, the Range and
|
|
Content-Range headers are not further specified.</p>
|
|
|
|
<h3 id="item09">6.3: Track dimension</h3>
|
|
|
|
<p class='phone'>A lot of discussion on the separator for
|
|
multiple values for track in the URI: sould we use comma or
|
|
semi-colon</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> we have resolved earlier
|
|
today to use semi-colon, unsure now why ?<br />
|
|
... discuss that tomorrow morning on the phone</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> we specify the Range and
|
|
Content-Range header on <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions</a></p>
|
|
|
|
<h3 id="item10">6.4: ID dimension</h3>
|
|
|
|
<p class='phone'><cite>Jack:</cite> Similar to track, except
|
|
that there is no sub-delim since we allow only ONE id in a
|
|
fragment<br />
|
|
... see also: <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers</a></p>
|
|
|
|
<h3 id="item11">7. Wrap up</h3>
|
|
|
|
<p class='phone'>ACTION-146?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-146 -- Jack
|
|
Jansen to identify and add in corrib any missing test cases for
|
|
temporal fragments -- due 2010-03-03 -- OPEN</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/146">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/146</a></p>
|
|
|
|
<p class='phone'>ACTION-147?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-147 --
|
|
Michael Hausenblas to add all MF WG members to corrib -- due
|
|
2010-03-05 -- OPEN</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/147">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/147</a></p>
|
|
|
|
<p class='phone'>Both must be done by tomorrow morning</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I will send a digest of
|
|
today's discussion tonight<br />
|
|
... tomorrow, we spend 1/2 hour with everybody to decide on the
|
|
comma vs semi-colon choice for multiple values for track</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I'm convinced we will have
|
|
problems when we combine multiple dimensions</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> time and tracks might mean
|
|
we select on time some bytes and we activate on UA the
|
|
track</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> NO, you select on time but
|
|
you have multiple video tracks (e.g. for mobile version)</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> we record the issue</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> we might mandate to use the
|
|
? in this case</p>
|
|
|
|
<p class='phone'><cite>ISSUE:</cite> Combining axis is probably
|
|
not going to be done by LC, but we should write somewhere that
|
|
this is doable</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ISSUE-16 -
|
|
Combining axis is probably not going to be done by LC, but we
|
|
should write somewhere that this is doable ; please complete
|
|
additional details at <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/16/edit">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/16/edit</a>
|
|
.</p>
|
|
|
|
<h3 id="item12">8. AOB</h3>
|
|
|
|
<p class='phone'>[meeting adjourned]</p>
|
|
</div>
|
|
|
|
<h2><a name="ActionSummary" id="ActionSummary">Summary of Action
|
|
Items</a></h2><!-- Action Items -->
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Yves to modify
|
|
the production rule for the track dimension in order to allow
|
|
multiple comma separated values [recorded in <a href=
|
|
"http://www.w3.org/2010/03/08-mediafrag-minutes.html#action01">http://www.w3.org/2010/03/08-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.135 (<a href=
|
|
"http://dev.w3.org/cvsweb/2002/scribe/">CVS log</a>)<br />
|
|
$Date: 2010/03/08 17:18:26 $
|
|
</address>
|
|
|
|
<div class="diagnostics"></div>
|
|
</body>
|
|
</html>
|