08-mediafrag-minutes.html 65.5 KB

Raw Blame History Permalink

<!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'>&lt;<cite>trackbot</cite>&gt; Date: 08 March
    2010</p>

    <p class='phone'>trackbot, start telecon</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Meeting: Media
    Fragments Working Group Teleconference</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Date: 08 March
    2010</p>

    <h3 id="item01">1. Administrative</h3>

    <p class='irc'>&lt;<cite>scribe</cite>&gt; scribenick:
    raphael</p>

    <p class='irc'>&lt;<cite>erik</cite>&gt; <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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>Yves</cite>&gt; <a href=
    "http://www.ietf.org/rfc/rfc3339.txt">http://www.ietf.org/rfc/rfc3339.txt</a></p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I am fine with
    rfc3339</p>

    <p class='phone'><cite>Yves:</cite> they all come from ISO</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>conrad</cite>&gt; 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'>&lt;<cite>jackjansen</cite>&gt; silvia, how
    about aaa?</p>

    <p class='irc'>&lt;<cite>davy</cite>&gt; +1</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; +1</p>

    <p class='irc'>&lt;<cite>erik</cite>&gt; +1</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; after femto
    comes atto, iirc...</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; +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'>&lt;<cite>conrad</cite>&gt; +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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; ups</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; <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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; I still stand to
    that decision</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; we use percent
    encoding, quotes don't help</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; Raphael: yes</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I agree with
    foolip</p>

    <p class='phone'>ACTIOn-150?</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; <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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; using or not using
    quotes?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; please don't make
    them optional, that way implementations are stilled forced to
    handle them</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>davy</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>erik</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; by using quotes we
    would be adding a fith point</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>guillaume</cite>&gt; examples?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; + only needs to be
    percent-encoded if we make + be replaced by a space.</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; 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'>&lt;<cite>Yves</cite>&gt; '+' is a reserved
    character in rfc3986 (sub-delims)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; ok, so a URL with +
    unescaped is invalid?</p>

    <p class='irc'>&lt;<cite>guillaume</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; + 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'>&lt;<cite>Yves</cite>&gt; foolip: not invalid,
    but interop issues</p>

    <p class='phone'>Philip, can you phone in for 15 minutes ?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; raphael: can I use
    Skype?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I have no real
    phone</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>Yves</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; yes</p>

    <p class='phone'><cite>Raphael:</cite> transformed by the
    browser</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; with the addition
    that I haven't tested all possible input</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; unreserved = ALPHA /
    DIGIT / "-" / "." / "_" / "~"</p>

    <p class='phone'>Jack summary: we have 3 sets of characters</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; "The only exception
    is for</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; percent-encoded
    octets corresponding to characters in the unreserved</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; or better still, in
    2.5:</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; "When a new URI
    scheme defines a component that represents textual</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; data consisting of
    characters from the Universal Character Set [UCS],</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; the data should
    first be encoded as octets according to the UTF-8</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; character encoding
    [STD63]; then only those octets that do not</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; correspond to
    characters in the unreserved set should be percent-</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; encoded."</p>

    <p class='phone'><cite>Raphael:</cite> I think I'm convinced
    that the quotes are therefore useless</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I am too :)</p>

    <p class='phone'>Jack is too</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; +1</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; +1</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; +1</p>

    <p class='irc'>&lt;<cite>davy</cite>&gt; +1</p>

    <p class='phone'>+1</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; +1</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; =</p>

    <p class='irc'>&lt;<cite>erik</cite>&gt; +1</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; ?</p>

    <p class='irc'>&lt;<cite>guillaume</cite>&gt; ?</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; Or should we
    vote %2b1?</p>

    <p class='irc'>&lt;<cite>guillaume</cite>&gt; %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'>&lt;<cite>jackjansen</cite>&gt; 3b2 otoh is an
    old unix machine...</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; unless we want to
    decide otherwise</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; fine, as long as we
    agree it's valid</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; t is in the
    unreserved set and thus rfc3986 recommends not encoding it</p>

    <p class='irc'>&lt;<cite>fdenoual</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 6.2.2.2.
    Percent-Encoding Normalization &lt;- explicitly talks about not
    encoding them</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; against which?</p>

    <p class='irc'>&lt;<cite>fdenoual</cite>&gt; Section 5.1.1</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; Against using
    pseudo-code fragements in normative text, as in 5.1.1</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I do not think we
    need to repeat what rfc3986 says about percent-encoding, so I
    am against a)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; a) seems
    redundant</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; b) otoh clarifies a
    lot - I don't mind the pseudo-code</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; why are you against
    it?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; if someone can
    define processing of name-value pairs by some other method,
    fine</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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 '&amp;' 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'>&lt;<cite>silvia</cite>&gt; section 4.2.3 has
    quotes in examles</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; mediasegment =
    namesegment / axissegment</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; *( "&amp;" (
    <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'>&lt;<cite>foolip</cite>&gt; I would like to
    speak</p>

    <p class='phone'>Yes, Philip, 2 sec</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; adding examples would
    be good</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; always helpful to
    clarify things for both programmers and users</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; you'll notice that
    there's no ABNF for &amp;-=-separated lists</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I wouldn't move it
    to another location - it's in the right place</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; 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'>&lt;<cite>jackjansen</cite>&gt; Yep, very first
    2 productions</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; axissegment = (
    timesegment / spacesegment / tracksegment )</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; *( "&amp;" (
    timesegment / spacesegment / tracksegment )</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I removed that,
    someone put it back it seems</p>

    <p class='phone'>:-)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; it doesn't make any
    sense to have both</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>jackjansen</cite>&gt; silvia, which
    rule is unclear, and why?</p>

    <p class='phone'>15 minutes break</p>

    <p class='irc'>&lt;<cite>guillaume</cite>&gt; ok</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; the rule in 4.1 is
    missing the percent-encoding</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; no, it's included in
    utf8string definition</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; unless we have ABNF
    for percent-encoding + UTF-8 then there cannot be a complete
    ABNF at the URI level</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; there are two
    levels</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; and the way it is
    now, the dimension value is not %encoded</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; ok, I'll be back in
    15</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; yes, I removed the
    parts that didn't make sense, now that they are back the spec
    is just nonsense</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; Philip, that's
    about which terminals you have. Parsing vs. Lexing.</p>

    <p class='phone'>close ACTION-150</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; ACTION-143 Move
    5.1.5 into a new section closed</p>

    <p class='phone'>close ACTION-144</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; ACTION-144 Move
    the section 5.1.1 to the top closed</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; jackjansen: ? What
    does that mean, in practice?</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; ok, time to go
    home, zakim seems to think... :-)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; e.g.</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; SYN-RECEIVED
    STATE</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; If SND.UNA =&lt;
    SEG.ACK =&lt; SND.NXT then enter ESTABLISHED state</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; and continue
    processing.</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; If the segment
    acknowledgment is not acceptable, form a</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; reset segment,</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt;
    &lt;SEQ=SEG.ACK&gt;&lt;CTL=RST&gt;</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; and send it.</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; silvia, as I said
    earlier, I am ok to have both</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; it's kind of
    pointless to have this discussion without an alternative
    available for evaluation</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; the most important
    thing is that it is actually defined how to process name-value
    pairs</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; Yves, I was just
    curious about your statement and investigated :)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I agree, I think we
    should have both</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; it will just be a
    challenge to make sure they actually express the same and don't
    contradict each other</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I'd prefer to just
    have one representation, for sanity</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; the two current ones
    don't express the same thing, at all</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; so we need to fix
    that</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; I think the last
    paragraph in 5.1.3 needs its own section, but the rest
    doesn't</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; I don't see any new
    syntax anywhere else</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; no processing?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; it's just
    "handling"</p>

    <p class='phone'>Why Philip ?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; you handle errors
    and non-errors in the same way</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; those should stay
    with the protocol</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; they are, but
    finding a better name for the section is difficult - got a
    proposal?</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; silvia, how
    about "implementation guidelines"?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; not guidelines,
    normative, absolute rules</p>

    <p class='phone'>status of section (normative vs not) is
    independent</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; it's not actually
    about implementation guidelines - it's about how to process
    actual values</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; raphael: good - just
    wanted to make sure case it's syntax, too :)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; just two different
    communication threads :)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; no no no</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I would like to
    speak :)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; raphael: no, there's
    no phone around</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; I like semantics</p>

    <p class='phone'><cite>Raphael:</cite> section 7 = semantics +
    error handdling</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I'd like to explain
    the different levels here</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; the syntax of this
    is *arbitrary* &amp;-=-separated strings</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I agree</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; the result of
    parsing this is a list of name-values</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; media fragments is
    modelled on top of this, not on the URI string</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; in my versions</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; fuly agree with
    philip</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; fully</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; so, the ABNF or
    whatever must reflect this</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; i.e. the ABNF in 4.1
    must be changed, or removed</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; jackjansen: because
    timeprefix and timeparam should be matched after splitting</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; and after
    percent-decoding and UTF8-decoding</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; i.e. they aren't on
    the same "level"</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; That's because
    urls are our main language.</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; if c++ was our
    main language it would be datastructures.</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; the current *segment
    syntaxes don't make this distinction</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; No, because it's
    semantics, not syntax.</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; Same would be
    true for c++ datastructure declarations...</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; are you missing the
    "timeprefix = timeparam" in 4.1 ?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; (and same for all
    other examples, saying that it's foo = bar)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>Yves</cite>&gt; the grammar says that
    it's foo = bar then bar is percent encoded (see def of
    utf8string)</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; so the grammar already
    says that you split, then decode</p>

    <p class='irc'>&lt;<cite>fdenoual</cite>&gt; Is is possible to
    express sthg like: segment = *(segmentname=segmentvalue)
    ?...</p>

    <p class='irc'>&lt;<cite>fdenoual</cite>&gt; ... and then
    express segmentname and segmentvalue</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; yes</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>fdenoual</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; there should be no
    spirit, just hard, unambiguous requirements</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; we should specify
    exactly what UAs should accept</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; otherwise we won't
    have interop</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; Philip, we
    cannot have requirements for extensions.</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I can hear</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; jjust not talk</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; ok</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; there is no
    requirement for extensions, but we have to specify the document
    so we allow them</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; we can be very sure
    that we want to add things like foo=bar, no?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; indeed, we need to
    have the spec written such that any name-value pair is
    parsed</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; because the syntax
    doesn't allow it</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; and only the ones
    that are relevant to us will be specified in the document</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; unless we want
    implementors to guess what we meant</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; right now the ABNF
    spec doesn't allow other name-value pairs</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; yes, jackjansen is
    on the right track</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I agree :)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; yes, what jackjansen
    is saying is exactly what I intended when making the processing
    section for name-value strings</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; excellent :))</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; indeed, it's
    important that implementations aren't required to understand
    all current and future possible syntax :)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; thanks, I will drop
    out now to have dinner</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>fdenoual</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; ; 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'>&lt;<cite>silvia</cite>&gt; it's already
    syntactically incorrect</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; with multiple tracks
    we are only changing the production rule of the value of the
    track segment</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; not all values of
    all segments</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; So assume
    track=audio;subtitle is correct. Now how about
    id=section1;section2 ?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 4.2.3</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; tracksegment =
    trackprefix "=" trackparam</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; trackprefix =
    %x74.72.61.63.6B ; "track"</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; trackparam =
    utf8string</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; change to</p>

    <p class='phone'>Yes, silvia, that is easy</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; tracksegment =
    trackprefix "=" trackparam [; trackparam]*</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>jackjansen</cite>&gt; +1</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; =</p>

    <p class='irc'>&lt;<cite>davy</cite>&gt; +1</p>

    <p class='irc'>&lt;<cite>erik</cite>&gt; +1;</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; +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'>&lt;<cite>silvia</cite>&gt; the semantics are an
    enumeration of the chosen tracks, right?</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>Yves</cite>&gt; 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'>&lt;<cite>Yves</cite>&gt; <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'>&lt;<cite>jackjansen</cite>&gt; 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'>&lt;<cite>conrad</cite>&gt; 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'>&lt;<cite>Yves</cite>&gt; foo=bar</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; in the uri:
    foo=b%XXr</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; in the header:</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; Toto: foo=bar</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; or</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; "syntax of
    name-value pairs", independent of anything else in the spec</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; Toto: foo=b%XXr</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; foolip, yes</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; URI parsing =&gt;
    name=value pairs =&gt; encode in HTTP</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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 =&gt; name=value pairs =&gt;
    encode in HTTP</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; which is
    interpreting the list of name-value pairs that resulted from
    the first step</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; URI parsing (percent
    decoding) =&gt; name=value pairs =&gt; (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'>&lt;<cite>Yves</cite>&gt; <a href=
    "http://www.example.com/foo#t=%34">http://www.example.com/foo#t=%34</a></p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; 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) =&gt;
    name=value pairs =&gt; (rfc2047encoding) HTTP</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; should be the new
    first part of section 4, which has the general uri media
    fragment parsing in it</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; <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'>&lt;<cite>foolip</cite>&gt; no, was that
    something spawned in another teleconf?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; yes, the current
    format allows a decimal point with no trailing digits</p>

    <p class='phone'>close ACTION-132</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>conrad</cite>&gt; ok, ie. in 11min
    time?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; <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'>&lt;<cite>conrad</cite>&gt; 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: &lt;dimension&gt; ':'
    &lt;unit&gt; '=' &lt;start-pos&gt; - &lt;end-pos&gt;</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: &lt;dimension&gt; ':' &lt;unit&gt; ' '
    &lt;real-start-pos&gt; '-' &lt;real-end-pos&gt; '/'
    (&lt;instance-length&gt; / "*" )</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; ok sounds fair</p>

    <p class='phone'><cite>scribe:</cite> and define
    &lt;instance-length&gt; depending on the unit</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; 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'>&lt;<cite>conrad</cite>&gt; 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'>&lt;<cite>conrad</cite>&gt; of course it is true
    that the existing caches will not catch fire or anything</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; :)</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; 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'>&lt;<cite>conrad</cite>&gt; 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'>&lt;<cite>conrad</cite>&gt; 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'>&lt;<cite>conrad</cite>&gt; 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'>&lt;<cite>conrad</cite>&gt; even if the resource
    being requested is a time range, it might first do:</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; Range-Equivalent:
    npt 10min-20min</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; Range: bytes
    0-10000</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; then next do:</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; Range-Equivalent:
    npt 10min-20min</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; Range: bytes
    10000-20000</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; etc.</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; the Range-Equivalent
    specifies the representation that is wanted</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; 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'>&lt;<cite>conrad</cite>&gt; so both these
    requests invoke the response header Content-Range-Equivalent:
    npt 10min-20min</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; (excuse the min
    specifier ;-)</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; 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'>&lt;<cite>Yves</cite>&gt; ( *LWS element *( *LWS
    "," *LWS element ))</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; can be shown as</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; 1#element</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; 2.1 Augmented BNF</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; (of RFC2616)</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; token = 1*&lt;any CHAR
    except CTLs or separators&gt;</p><a name="action01" id=
    "action01"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>Yves</cite>&gt; <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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; <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'>&lt;<cite>trackbot</cite>&gt; ACTION-147 --
    Michael Hausenblas to add all MF WG members to corrib -- due
    2010-03-05 -- OPEN</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; <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'>&lt;<cite>trackbot</cite>&gt; 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 />

  &nbsp;<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>