08:01:01 RRSAgent has joined #mediafrag 08:01:01 logging to http://www.w3.org/2009/09/17-mediafrag-irc 08:01:03 RRSAgent, make logs public 08:01:03 Zakim has joined #mediafrag 08:01:05 Zakim, this will be IA_MFWG 08:01:05 ok, trackbot; I see IA_MFWG(F2F)4:00AM scheduled to start now 08:01:06 Meeting: Media Fragments Working Group Teleconference 08:01:06 Date: 17 September 2009 08:01:18 Agenda: http://www.w3.org/2008/WebVideo/Fragments/wiki/FourthF2FAgenda 08:01:40 Meeting: Media Fragments Working Group 4th F2F Meeting (Virtual) 08:01:47 I have made the request to generate http://www.w3.org/2009/09/17-mediafrag-minutes.html raphael 08:02:00 Chair: Erik, Raphael 08:03:00 IA_MFWG(F2F)4:00AM has now started 08:03:07 + +0329331aaaa 08:03:15 davy has joined #mediafrag 08:03:45 +mhausenblas 08:04:15 + +61.2.801.2.aabb 08:04:21 +raphael 08:04:51 erik has joined #mediafrag 08:04:56 Zakim, aabb is silvia 08:04:56 +silvia; got it 08:04:56 zakim, aaaa is erik 08:04:57 +erik; got it 08:05:09 zakim, who is here? 08:05:09 On the phone I see erik, mhausenblas, silvia, raphael 08:05:10 On IRC I see erik, davy, Zakim, RRSAgent, jackjansen, raphael, mhausenblas, silvia, trackbot, Yves 08:05:19 franck has joined #mediafrag 08:05:45 +Yves 08:08:02 Present: Davy, Erik, Michael, Raphael, Yves, Silvia, Franck (irc), Jack (irc) 08:08:06 Gui has joined #mediafrag 08:08:31 Topic: Specification discussion 08:09:02 conrad has joined #mediafrag 08:10:32 Erik: let's discuss first the aspect ratio issue 08:10:37 Scribe: raphael 08:10:41 Scribenick: raphael 08:10:41 zakim, mute me 08:10:41 silvia should now be muted 08:11:01 Davy: in my opinion, the aspect is just another representation of the video, this is not a part of the video 08:11:06 + +2712841aacc 08:11:14 zakim, ack Yves 08:11:14 I see no one on the speaker queue 08:11:33 zakim, aacc is Gui 08:11:33 +Gui; got it 08:11:40 zakim, unmute me 08:11:40 silvia should no longer be muted 08:11:42 Yves: I barely agree with the fact that aspect is a different thing, but from the processing point of view, this is also something that requires transcoding 08:11:58 ... I'm happy to remove this use case if people are not comfortable with it 08:12:24 zakim, aacc is Gui 08:12:24 sorry, raphael, I do not recognize a party named 'aacc' 08:12:33 zakim, ack Gui 08:12:33 I see silvia on the speaker queue 08:12:49 zakim, mute me 08:12:49 Gui should now be muted 08:12:58 zakim, ack Silvia 08:12:58 I see no one on the speaker queue 08:13:46 tmichel has joined #mediafrag 08:13:53 Silvia: I just respond to Yves, this is the server who does the clipping, but I think that in the case of the ratio, the server should do nothing ... this is up to the client to add the black parts 08:14:09 franck has joined #mediafrag 08:14:12 zakim, unmute me 08:14:12 Gui should no longer be muted 08:14:13 ... so I see no reason for a use case, this is a presentation issue and not a fragment issue 08:14:27 hi all, will try to make the call (romm issue!) 08:14:35 zakim, mute me 08:14:35 Gui should now be muted 08:14:46 zakim, mute me 08:14:46 silvia should now be muted 08:15:04 PROPOSED RESOLUTION: take the aspect feature out of the spec and of our requirements 08:15:13 +1 08:15:15 +1 08:15:15 +tmichel 08:15:16 +1 08:15:20 +1 08:15:23 +1 08:15:25 +1 08:15:33 zakim, unmute me 08:15:33 Gui should no longer be muted 08:15:39 +1 (and explain why in the doc) 08:16:00 apect ratio changes between what the server can provide and what the client wants to present are a presentation issue; one could either clip the video or add black bars; this should be up to the client to decide, not the server 08:16:01 +1 08:16:25 RESOLUTION: we agree that aspect ratio is not a fragment and will not be something that we can address with a Media Fragment URI 08:17:01 ACTION: Erik and Davy to write a paragraph in the documents to explain why we don't include this feature in the spec (rationale) based on the group analysis 08:17:02 Created ACTION-109 - And Davy to write a paragraph in the documents to explain why we don't include this feature in the spec (rationale) based on the group analysis [on Erik Mannens - due 2009-09-24]. 08:17:05 zakim, mute me 08:17:05 Gui should now be muted 08:17:18 +shadi 08:18:44 Now, let's discuss the role of the ? vs # 08:18:49 Silvia summary: http://blog.gingertech.net/2009/09/08/uri-fragments-vs-uri-queries-for-media-fragment-addressing/ 08:18:54 zakim, unmute me 08:18:54 silvia should no longer be muted 08:19:48 Silvia: I look at what Yves suggested, query and fragment are different depending on the need of trascoding or not 08:19:56 Zakim, mute me 08:19:56 sorry, conrad, I do not know which phone connection belongs to you 08:20:04 ... fragments, as it is defined currently, is something that needs to be resolved locally by the UA 08:20:14 zakim, shadi is conrad 08:20:14 +conrad; got it 08:20:21 Zakim, mute me 08:20:21 conrad should now be muted 08:21:33 Silvia: any comments ? 08:22:05 Michael: if we have transcoding, then URI queries should be used? 08:22:08 q+ 08:22:09 I agree on differentiation # for client nav ? for server transcoding 08:22:47 Silvia: yes to Michael question 08:23:19 Michael: my only concern is the extra complexity introduced for the implementors 08:23:56 Silvia: we are looking at various dimensions, we are pretty sure that for the temporal dimension, there will be often no transcoding required for most of the formats 08:23:59 ... so no problem 08:24:10 ... the problem will happen for the spatial dimension 08:24:42 ... where are not sure yet, when transcoding will be required ? always ? 08:25:28 ... I think therefore it is necessary to have solution for both cases when we need transcoding and we don't need 08:25:35 Conrad: with /query/ we can always go back to the server, with fragments the UA has to do something 08:25:58 Yves: conrad yes or no, yes if it receive the whole thing back, no if the server just send what's needed 08:26:34 I have made the request to generate http://www.w3.org/2009/09/17-mediafrag-minutes.html raphael 08:26:57 Present+ Conrad 08:27:28 Silvia: look at the example I post today, everytime you click, it refresh the pages, this is very painful ... 08:27:32 ... this is what we want to change 08:27:41 saw that. The clickthrough in the youtube example uses 2 separate videos that interlink each others 08:28:13 q+ 08:28:17 No Gui, see that http://lists.w3.org/Archives/Public/public-media-fragment/2009Sep/0087.html 08:29:43 zakim, ack me 08:29:43 I see davy on the speaker queue 08:30:29 Michael: I follow silvia's argumentation, though, for the sake of a simple standard I'd opt for # only 08:31:09 Raphael, yes, that's the one I'm referring to. According to what I read, there were two similar looking videos involved to provide the linking effect for time offsetting. 08:32:18 Raphael: my concern is then what will happen with the spatial dimension ... since it requires transcoding most of the time 08:32:55 Yves: the whole document will be served 08:33:08 ... since the server cannot satisfy the range request 08:33:13 Silvia: I agree 08:33:42 FD has joined #mediafrag 08:33:56 what about JPEG2000? 08:34:38 Raphael: I have the feeling then that we are specifying a feature, #xhwh=100,100,400,400 that will never been satisfiable ! 08:34:48 + +aadd 08:34:54 Davy argues that JPEG2000 might do it? 08:35:12 Silvia: in the future, some codecs can do it ... 08:35:25 zakim, ack davy 08:35:25 I see no one on the speaker queue 08:35:37 normal jpg can do this with block elvel as well, no? 08:35:43 zakim, aadd is FD 08:35:43 +FD; got it 08:36:08 Silvia: I think this is not a new issue that comes up, we have discussed that a long time ago ... 08:36:18 zakim, mute me 08:36:18 silvia should now be muted 08:37:57 Raphael: we will need to document that, and particularly add many test cases, when the server needs to transcode to satisfy the range request 08:38:26 I think what we have to do in our standard is to provide means for any kind of resource to allow creation of a media fragment URI that can request access to a fragment; some will be able to satisfy it from the local resource, others only with transcoding; thus we need to specify our addressing scheme for both possiblities: ? and # 08:38:29 Yves: this is not an out of range case 08:38:38 ... this is something that is forbidden 08:38:46 +1 to Silvia 08:39:17 Yves: 416 is only used when it is possible to do a range request, but you have a out of bond case 08:39:26 I agree with Silvia : "? AND #" 08:39:27 ... here, we have something that cannot be applied 08:40:09 Yves: in the case of transcoding, the server will then must serve the whole content with a 200 08:40:10 I also agree that we need to define both ? and # 08:40:46 rrsagent, draft minutes 08:40:46 I have made the request to generate http://www.w3.org/2009/09/17-mediafrag-minutes.html erik 08:40:55 Yves: so the server needs to identify whether transcoding is necessary or not, and then rely on the default HTTP rules 08:40:59 +1 to Silvia too 08:41:12 +1 to Silvia 08:41:40 ? and # 1. Gives more control to the user 2. Makes our syntax specification usable by current server side implementations 08:41:41 +1 to silvia 08:42:22 Michael: I hesitate to make a big +1, because of the complexity 08:42:55 ... but I can live with it ... I would prefer to care about # now, and work on ? later on 08:43:15 Davy: from an implementation point of view, I think the server has not a lot of extra work 08:43:35 ... the query thing comes almost for free when you implement the hash 08:43:45 Michael: I'm thinking on both the UA and the server sides 08:44:05 zakim, unmute me 08:44:05 silvia should no longer be muted 08:44:09 ... principle thing, the more options you have, the more test cases and things to think about 08:44:35 ... but I understand the need and the arguments from the others 08:44:51 Silvia: I think you're totally right, we don't want to add complexity we don't need 08:45:24 ... focus is on the hash, I see the ? as an optimization ... the communication aspect is already here anyways 08:45:29 s/anyways/anyway 08:46:08 Silvia: for query, we need to specify nothing almost, this is already handled 08:46:34 ... in fact, we only specify the communication for the #, so to some extent you're ight 08:46:49 ... we are saying that the URI syntax can also be used for ? 08:47:13 Michael: we are requiring that both are normative ? this is MUST or a SHOULD ? 08:47:32 Silvia: the specification of a URL does not say anything about the implementation 08:47:53 ... we open the possibility to create URL in a standard format 08:48:39 ... correct me if I'm wrong, but I think we specify just the syntax of the URL and the way we should parse it 08:48:50 Silvia: the hash resolution part must be normative 08:49:03 an implementation that claims to support # must do it this way 08:49:07 an implementation that claims to support ? must do it that way 08:49:14 ? and # - 3. Also precise if the user wants data in or out of context ? 08:49:15 ... for the query, we could suggest to use the same way 08:49:56 Michael: if this is not normative, does that have an incident on interoperability 08:50:04 ... are we after a MUST or a SHOULD? 08:50:10 i suggest that an implementation must state what it claims to support (eg. through http headers, uri parameters or whatever) -- and if it makes that claim, it must do it as described 08:50:43 +1 08:50:43 Michael: in the case of ?, I think the MUST is a strong constraint 08:50:51 whereas if it doesn't make that claim (eg. all existing urls) then this standard does not apply 08:50:57 Raphael: I'm well aware of the terminology 08:52:36 zakim, mute me 08:52:36 silvia should now be muted 08:52:48 we specify a MUST on the method of advertising that this standard applies to this URL 08:53:36 as conrad says: if I claim conformance, I must follow the protocol - otherwise the communication cannot be resolved 08:53:59 zakim, unmute me 08:53:59 silvia should no longer be muted 08:54:02 we need to specify how conformance is claimed 08:54:33 Michael: am I the only one who doesn't really get what will be specified normatively in the case of the ? 08:55:06 Silvia: are you talking about the communication between the UA and the server ? 08:55:12 when using query '?' you may have to specify the communication to get context info (Link header for example) 08:55:41 Raphael: oups, you're right Frank, thanks for the heads up :-) 08:56:45 Frank: I just wanted to remember the point of using the link header in the response of the server ... so the UA gets the context of the parent resource 08:57:10 Frank, can you please be more specific? Are you referring to LRDD? 08:57:16 Silvia: are you suggesting we write a MAY use instead of a MUST use? 08:57:22 Is the difference between ? and # introduce a difference between secondary resource and a derived resource? 08:57:57 zakim, mute me 08:57:57 silvia should now be muted 08:58:28 Frank: I have no precise idea of how the link header semantics should be used 08:58:50 I agree with Frank. Context should be done via LRDD (http://tools.ietf.org/html/draft-hammer-discovery-03) 08:58:58 ... but the communication between the server and the UA must be alterated because of the addition of the link header 09:00:17 Yves: for me, the link header should always be used in the query case 09:00:22 ... we could mandate that 09:00:42 ... I don't think there is a current property / value for that already, we might look for it 09:00:47 ... invent a part-of ? 09:00:53 i think the link header is useful, but should not be MUST 09:01:00 ... perhaps there is already something already 09:01:29 Michael: LRDD specifies only [to complete] 09:02:04 Yves: we may have a separate RFC for that ... 09:02:17 Michael: problem of timeline, it will be ready on time ? 09:02:31 I agree with conrad - if the resource has all the information about the offsetting etc inside it, it doesn't need to be accompanied by parent information 09:02:35 Yves: I don't exactly when the RFC will be ready ... but I believe the time frame is correct 09:03:00 Zakim, unmute me 09:03:00 conrad should no longer be muted 09:03:13 http://tools.ietf.org/id/draft-nottingham-http-link-header-06.txt 09:03:32 http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt 09:03:41 Conrad: I think the header is useful, but why mandating to send the whole context ? 09:03:55 s/LRDD specifies only [to complete]/LRDD specifies the semantics for relating a resource and its description via describedBy for three cases (link element, Link: header, and well-known location) 09:03:58 +1 with conrad 09:04:03 Agree with Conrad, required mainly for display/clipping 09:04:28 Zakim, mute me 09:04:28 conrad should now be muted 09:05:14 RRSAgent, draft minutes 09:05:14 I have made the request to generate http://www.w3.org/2009/09/17-mediafrag-minutes.html mhausenblas 09:05:42 Raphael: time to summarize ... who wants to give it a try? 09:05:46 [silence] 09:05:51 isn't the summary that both are useful in different situations? 09:05:51 [dead silence] 09:05:53 resolution draft: we agree that there is a need for allowing both a ? and a # specification for media fragments 09:06:42 we further agree that our main focus is #, but that the communication that we define between client and server will be adapted also to the ? case 09:07:00 Michael: I still have a question 09:07:22 ... what's happen when there is both ? there is a hierarchy, query first and then fragment 09:07:28 such that for media fragment URIs that cannot be resolved with # because it needs transcoding, ? can be used 09:07:47 ... what's happen when: ?t=10,30#15 09:07:47 zakim, unmute me 09:07:47 silvia should no longer be muted 09:08:11 the ? defines a URL, the # is a relative offset 09:08:25 Silvia: I think this is obvious to what happens ... 09:08:42 ... the query generates a new resource, and the fragment is a new relative offset to this new resource 09:08:57 ... in raphael's case, it will start at 25s 09:09:03 zakim, mute me 09:09:03 silvia should now be muted 09:09:05 +1 09:09:13 +1 that makes sense 09:09:36 since a URI with a ? part creates a new resource, we have to do the fragment offset on the new resource, which in this case means it will start at 25s 09:09:56 +1 to the proposal. I'm fine with silvia's explanation 09:12:01 -Yves 09:12:50 zakim, unmute me 09:12:50 silvia should no longer be muted 09:13:04 Raphael: our starting point is http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#fragment-query 09:13:49 Silvia: does someone have any issue in my blog post? 09:14:55 ... if not, then we can give an action to someone to draft a good exaplanation based on my post and this discussion on irc 09:15:15 Michael: wondering if there is a type in silvia's example at http://blog.gingertech.net/2009/09/08/uri-fragments-vs-uri-queries-for-media-fragment-addressing/ 09:15:22 ... Range: seconds=20- and then Content-Range: seconds 11.85-21.16/3600 09:15:27 ... shouldn't this be seconds=12- ...? 09:15:41 Silvia: no, the server works in a best effort 09:15:48 ... I am trying to explain that content may not be able to be resolved to the required resolution depending on the codec 09:16:01 ... this is an example of what a server might only be able to do ... 09:16:36 ... as a server, you ask for a time range, but I can only serve you that, and then the UA needs to throw away what's in extra 09:16:58 ... no way of doing that differently, since the UA will not be able to decode it otherwise 09:17:15 the client requests t=20, the previous keyframe is t=12 so the server sends from there 09:17:48 Raphael; this 8s is odd :-) there are more I-Frames in the middle :-) 09:17:57 Michael: I'm just suggestion there is a type 09:18:01 s/type/typo 09:18:13 s/suggestion/suggesting 09:18:26 ignore my keyframe explanation here :) 09:18:31 check apple movie trailers: very few I Frames ... 09:19:39 zakim, mute me 09:19:39 silvia should now be muted 09:19:40 Silvia: the remaining of the post talks about the headers, but this is for next half of the meeting 09:19:41 one thing at the time 09:20:43 Michael: my guess is that Silvia is the best volunteer to draft the summary 09:21:00 ok :) 09:21:28 zakim, unmute me 09:21:28 silvia should no longer be muted 09:21:42 zakim, mute me 09:21:42 silvia should now be muted 09:22:33 zakim unmute me 09:22:35 ACTION: Silvia to draft a summary starting from her blog post and these IRC minutes in the document 09:22:35 Created ACTION-110 - Draft a summary starting from her blog post and these IRC minutes in the document [on Silvia Pfeiffer - due 2009-09-24]. 09:22:45 Topic: 2. Protocol discussion 09:22:50 ACTION-69? 09:22:50 ACTION-69 -- Conrad Parker to draw a representation of the general structure of a media resource, for streamable formats (H/H' + K + D1 + D2 + D3) -- due 2009-04-24 -- OPEN 09:22:50 http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/69 09:22:56 Zakim, unmute me 09:22:56 conrad should no longer be muted 09:23:06 zakim, unmute me 09:23:06 silvia should no longer be muted 09:23:40 zakim, mute me 09:23:40 silvia should now be muted 09:23:48 Conrad: I wanted to describe how ogg files are structured 09:24:22 ... and if one is a sub part of another, then which parts changed or not 09:24:48 if you have an original file H D1 D2 D3 09:24:56 Raphael: is this drawing available somewhere ? 09:25:00 and you make a subview that goes H' D2 D3 09:25:15 raphael - no, it is not available, hence my comment 09:25:33 Michael: I think conrad needs to draw it (even just with pencil and scan it in - and we postpone it to tomorrow ...) 09:25:42 with keyframes, you might end up with something like H' D2' D3 09:26:07 I'd also like to point out that different containers/codecs work differently and have different challenges 09:26:42 Conrad: I will draw it tonight, postpone the visualization tomorrow morning 09:27:33 Raphael: two more things to discuss, headers and range syntax 09:27:50 Zakim, mute me 09:27:50 conrad should now be muted 09:28:14 Raphael: should we start with the Range syntax ? 09:28:18 [silence] 09:28:47 Yves's proposal: http://lists.w3.org/Archives/Public/public-media-fragment/2009Sep/0035.html 09:30:01 let's not mix formats 09:30:04 Yves made 2 suggestions 09:30:16 ... 1: unit and then values 09:30:23 ... 2: unit can be mixed 09:30:35 Michael: second option seems more comple 09:30:41 s/comple/complex 09:30:56 Raphael: we don't need to mix units, anyway, the URI syntax does not permit it 09:32:02 Yves proposal just concerns the time dimension ... more issue with other dimensions 09:32:30 Frank: what will be the duration of the track dimension? 09:32:45 Michael: track and ID do not have dimensions 09:32:47 Michael: track is identified by a name, full stop 09:33:09 Raphael: is track and id a Range request? 09:33:28 ... if yes, then what is the Content Range ? 09:34:04 ... if this is: Content-Range: track 'video' / what is behind the '/' ? 09:34:07 q+ 09:34:08 you could talk about the number of labels 09:34:23 track does not belong in Range 09:34:40 rssagent, draft minutes 09:34:57 ack raphael 09:35:25 rrsagent, draft minutes 09:35:25 I have made the request to generate http://www.w3.org/2009/09/17-mediafrag-minutes.html erik 09:35:47 zakim, unmute me 09:35:47 silvia should no longer be muted 09:35:51 q+ to talk about orthogonal addressing concept continuos (time/spatial) and discrete (track/ID) 09:35:54 Zakim, unmute me 09:35:54 conrad should no longer be muted 09:36:09 zakim, mute me 09:36:09 silvia should now be muted 09:36:18 ack conrad 09:36:42 Silvia: yes, good point from Conrad, why does he think track and id are not range request? 09:37:14 Conrad: I think a track is not something one can see as a range 09:37:25 Track is not a time range, at best, Track is a Byte range which correspond to this piece of the media only holding the track, at worste, its muxed and interleaved and has no range 09:37:27 ... i admit, tricky issue 09:37:34 ack me 09:37:34 mhausenblas, you wanted to talk about orthogonal addressing concept continuos (time/spatial) and discrete (track/ID) 09:37:36 zakim, ack michael 09:37:37 I see no one on the speaker queue 09:37:58 range should be for continuous addressing 09:38:03 Zakim, mute me 09:38:03 conrad should now be muted 09:38:03 Raphael: Guillaume, we are not talking about time range ... but range request, expressed in bytes or other units 09:38:38 Michael: Orthogonal addressing concepts: time / spatial (continuous) vs track / id (discrete) 09:38:55 Raphael: I would say "id" is even different, since this is a combination of the others 09:39:24 Raphael: I would put id aside 09:39:31 raphael: I was answering to michael mentioning that track COULD be a time range, and I think it just can't 09:39:36 you can't define a distance metric over track ;-) 09:39:41 so do we need different mechanisms to resolve id and track? 09:40:08 so this is why i was suggesting a Fragment header 09:40:10 Michael & Raphael : Ok 09:40:12 maybe track can only ever be used with ? 09:40:15 http://www.w3.org/2008/WebVideo/Fragments/wiki/Server-parsed_Fragments 09:40:28 http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_Examples#Track.2BTime_Fragment_URI 09:40:40 zakim, unmute me 09:40:40 silvia should no longer be muted 09:40:42 There is a case where what's behind the track video / 1 could be an index in case many audio or video tracks 09:41:14 Silvia: when we started to talk about fragments, we were talking about continous set of bytes 09:41:20 ... for temporal, it was a reasonable assumption 09:41:35 ... for spatial, it starts to be a problem in most of the coding format 09:41:48 ... for track, as Conrad said, it is difficult 09:42:01 ... is it a case of transcoding that can be resolved only with transcoding ? 09:42:14 if an adaptation can be expressed in terms of byte ranges, it is not transcoding 09:42:18 zakim, mute me 09:42:18 silvia should now be muted 09:42:21 ... I'm not sure about that either ... I'm very uncertain so far, I need to make my mind 09:42:58 I have made the request to generate http://www.w3.org/2009/09/17-mediafrag-minutes.html raphael 09:43:01 zakim, unmute me 09:43:01 silvia should no longer be muted 09:43:26 Michael: I'm afraid we are introducing something too complex 09:43:38 Raphael: accessibility is the main use case for tracks and it is very important 09:43:55 s/something too complex/something too complex with the ID concept; track might be sufficient 09:44:18 a track request without transcoding may result in thousands of byte ranges for concatenation 09:44:21 Silvia: our focus is on time ... this needs to get more thoughts 09:44:26 zakim, mute me 09:44:26 silvia should now be muted 09:44:37 Gui agrees with Conrad 09:45:32 what's wrong with that if the server joines these byte ranges? 09:45:44 Raphael: expectation is to have a 2nd WD ready by the end of the month to be published 09:46:10 Silvia: would suggest to focus on temporal domain for this next version of the WD, such that people can start using it - the browser vendors and HTML5 are keen to get into it 09:46:30 Davy: I don't think this is an issue for the server to do the join of the bytes ranges and serve the joint part 09:46:41 zakim, unmute me 09:46:41 silvia should no longer be muted 09:46:51 davy, yes, that case is not an issue 09:46:51 zakim, mute me 09:46:51 silvia should now be muted 09:47:15 zakim, unmute me 09:47:15 silvia should no longer be muted 09:47:45 for this resolution we would need to specify an exact set of range names 09:48:14 Raphael: time for resolution 09:48:21