08:15:49 RRSAgent has joined #mediafrag 08:15:49 logging to http://www.w3.org/2010/03/08-mediafrag-irc 08:15:51 RRSAgent, make logs public 08:15:51 Zakim has joined #mediafrag 08:15:53 Zakim, this will be IA_MFWG 08:15:53 ok, trackbot, I see IA_MFWG(F2F)2:00AM already started 08:15:54 Meeting: Media Fragments Working Group Teleconference 08:15:54 Date: 08 March 2010 08:16:40 raphael has joined #mediafrag 08:16:47 trackbot, start telecon 08:16:49 RRSAgent, make logs public 08:16:51 Zakim, this will be IA_MFWG 08:16:51 ok, trackbot, I see IA_MFWG(F2F)2:00AM already started 08:16:52 Meeting: Media Fragments Working Group Teleconference 08:16:52 Date: 08 March 2010 08:19:29 Topic: 1. Administrative 08:20:25 Present: Davy, Erik, Yves, Frank (observer), Jack, Raphael, Silvia (remote), Conrad (remote), Michael (remote), Philip (remote), Guillaume (remote) 08:20:43 Chair: Erik, Raphael 08:20:57 scribenick: raphael 08:21:22 Yves announced that W3C has a new CEO 08:21:33 s/Yves announced that W3C has a new CEO// 08:23:41 http://www.w3.org/2008/WebVideo/Fragments/wiki/FifthF2FAgenda 08:23:44 Agenda: http://www.w3.org/2008/WebVideo/Fragments/wiki/FifthF2FAgenda 08:24:42 Raphael: Minor changes in the agenda 08:24:59 ... tomorrow, we switch the 2 sessions on implementation report and test cases 08:25:11 ... we will finish earlier, 15:30 PM most likely 08:29:08 Erik announced the nice dinner we will have, just to make jealous the remotes :-) 08:29:46 I'm having waffles and ice cream for dinner right now :) 08:30:33 OK, we will start, Conrad, Philip Michael, phone when you can, asap :-) 08:30:58 Topic: 2. Media Fragments syntax 08:31:29 First thing to consider: WG decision for expressing wall-clock time code 08:32:02 http://www.ietf.org/rfc/rfc3339.txt 08:32:17 I am fine with rfc3339 08:32:36 Yves: they all come from ISO 08:32:42 as reference 08:32:52 ... RFC3339 is just a recap, but defined with ABNF 08:34:09 RFC3339 abstract: "This document defines a date and time format for use in Internet 08:34:09 protocols that is a profile of the ISO 8601 standard for 08:34:09 representation of dates and times using the Gregorian calendar. 08:34:35 seems like a fine reference to me 08:34:54 Yves: there is no diff than with the ISO, except that it is defined with ABNF and we can copy directly the def 08:35:00 +mhausenblas 08:37:04 Raphael: i remind you of the Resolution WG wiki page, http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions 08:38:30 Proposal: Use RFC3339 for expressing time and date format (same than ISO8601 but expressed in ABNF) 08:39:03 silvia, how about aaa? 08:39:27 +1 08:39:40 +1 08:39:42 +1 08:39:45 after femto comes atto, iirc... 08:39:47 +1 08:39:57 +1 08:40:24 RESOLUTION: we will express wall-clock time code with RFC3339 08:40:32 I have made the request to generate http://www.w3.org/2010/03/08-mediafrag-minutes.html raphael 08:41:05 +1 08:43:37 Raphael: Yves is editing the spec _now_ so we save some actions :-) 08:43:50 ... the action is doing the changes in the spec 08:44:16 the aim is to have FPWD at the end of tomorrow, so editing will be highly necessary 08:44:16 Second thing to consider: WG decision: having quotes or not for name and id dimensions 08:44:42 can I point us to http://www.w3.org/2002/09/wbs/42785/MFRAGSYNTAXSEGMENT/results 08:45:00 ups 08:45:09 http://www.w3.org/2002/09/wbs/42785/MFRAGSYNTAXQUOTE/results 08:45:25 we had the discussion about quotes before 08:45:47 Yes, this is what Jack was remining us earlier 08:46:27 See also the 3rd point in http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_URI_Syntax 08:46:36 "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) " 08:48:15 I still stand to that decision 08:48:26 across all relevant dimensions 08:48:49 Raphael: relevant dimensions = track and id ? 08:49:14 Jack: if we don't use quotes, is there some strings we cannot specify ? 08:49:59 ... we thought there are some strings that require it, Philip states it is not necessary 08:50:19 ... I tried toget some counter examples, I found just one: YouTube, all the others work like Philip said 08:50:24 we use percent encoding, quotes don't help 08:50:50 Raphael: yes 08:51:12 I agree with foolip 08:51:26 ACTIOn-150? 08:51:26 ACTION-150 -- Erik Mannens to summarize the discussion on the quotes in a mail or on the wiki -- due 2010-03-03 -- OPEN 08:51:26 http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/150 08:51:50 but in the end, we cannot prohibit people from using them, so I would simply recommend against them in the spec 08:52:12 Are the single quotes helping? Apparently not, in this case, they have no value 08:52:43 To silvia, Davy didn't get any issues at all 08:52:56 using or not using quotes? 08:53:00 please don't make them optional, that way implementations are stilled forced to handle them 08:53:04 I agree: *if* quotes don't help we shouldn't use them. 08:53:40 To silvia: using it 08:54:09 Raphael: I agree with Philip and Jack, if they are not necessary, then we should NOT use them 08:54:17 so, Davy used quotes - did he use percent-encoding in his implementation? or were the quotes necessary because he didn't use percent-encoding? 08:55:27 Silvia: indeed, we did not use percent-encoding because of the quotes 08:56:41 Raphael: so the question is between percent-encoding or single quotes? 08:57:42 Erik: I prepared a word document for my action-150, not online yet 08:58:00 + +2712841aabb 08:58:15 zakim, aabb is Guillaume 08:58:15 +Guillaume; got it 08:58:50 btw: 7.3. Back-End Transcoding in http://www.ietf.org/rfc/rfc3986.txt also talks about percent encoding in name-value pairs (here for query) 08:59:32 Erik listed 4 problems that will be list in the minutes 09:01:04 Raphael raised possible problems on this issue on http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0002.html 09:02:04 those aren't problems, those are limitations already listed in the spec 09:02:33 For the 3rd limitations, the "+" character, we should warn that the + should be %-encoded 09:02:35 by using quotes we would be adding a fith point 09:03:12 or are we not discussion percent-encoding vs quotes any longer? 09:04:13 Philip, yes, we are still discussing percent-encoding vs quotes 09:04:23 ... though the discussion is going in various ways 09:04:39 examples? 09:05:46 + only needs to be percent-encoded if we make + be replaced by a space. 09:06:05 no, because of the duality of + used in the past to encode ' ' 09:06:49 Raphael: we are back to the original point of discussion 09:06:53 '+' is a reserved character in rfc3986 (sub-delims) 09:07:37 I think that should be borne by those who use PHP and friends to parse MF, despite the problems 09:07:49 Jack: 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 09:08:01 ok, so a URL with + unescaped is invalid? 09:08:54 what are current and future best practice out there : less readable % encoded OR more structured quote based? 09:08:55 Jack: between quotes, the subdelim are still valid 09:09:13 Guillaume, read the long thread of dicussion we had :-) 09:09:59 + is a sub-delim according to http://www.ietf.org/rfc/rfc3986.txt and as such already needs to be %encoded 09:10:01 foolip: not invalid, but interop issues 09:10:40 Philip, can you phone in for 15 minutes ? 09:10:56 raphael: can I use Skype? 09:11:03 I have no real phone 09:11:19 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 09:11:27 Yes PHilip 09:11:52 zakim, code? 09:11:52 the conference code is 3724 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), raphael 09:13:45 Raphael: 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 09:15:01 the spec says that you have to %encode the content values 09:16:09 Jack: 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 09:16:26 silvia; yes, that is right, encode values 09:17:29 Erik: is that the case also for the ' ' (space) ? 09:18:42 ... so why you would like to put quotes, if the browser doesn't transform the space into %20 ? 09:21:59 well, space is not part of the delimiters, but section 2.1 explicitly talks about %20 09:22:16 Philip: any special character which is not part of the reserved set is transformed into a %-encoding version 09:22:26 Raphael: this is what you said Philip? 09:22:32 yes 09:22:40 ... transformed by the browsr 09:22:47 s/browsr/browser 09:22:48 with the addition that I haven't tested all possible input 09:24:35 unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" 09:24:57 Jack summary: we have 3 sets of characters 09:25:25 "The only exception is for 09:25:25 percent-encoded octets corresponding to characters in the unreserved 09:25:25 set, which can be decoded at any time." 09:25:28 ... unreserved: there are never been encoded (if you do it, you type too much) 09:25:35 so, everything that is not in the unreserved set has to be encoded 09:25:47 ... reserved: delim and sub delim, MUST be %-encoded 09:25:51 according to http://www.ietf.org/rfc/rfc3986.txt 09:26:44 ... the rest ... which is just illegal (including the space) 09:27:02 or better still, in 2.5: 09:27:07 "When a new URI scheme defines a component that represents textual 09:27:07 data consisting of characters from the Universal Character Set [UCS], 09:27:07 the data should first be encoded as octets according to the UTF-8 09:27:07 character encoding [STD63]; then only those octets that do not 09:27:07 correspond to characters in the unreserved set should be percent- 09:27:08 encoded." 09:28:19 Raphael: I think I'm convinced that the quotes are therefore useless 09:29:00 I am too :) 09:29:05 Jack is too 09:29:17 Whatever you say, Chairman 09:30:41 Proposa: 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. 09:30:54 s/Proposa/Proposal 09:31:13 +1 09:31:17 +1 09:31:19 +1 09:31:20 +1 09:31:22 +1 09:31:22 +1 09:31:22 = 09:31:26 +1 09:31:31 ? 09:31:37 09:31:41 ? 09:32:09 Or should we vote %2b1? 09:32:37 %2b1 then 09:33:05 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 09:33:23 3b2 otoh is an old unix machine... 09:35:12 note that even the names can be percent encoded, even if it's ugly 09:35:17 Jack: 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 RFC3339 for that. Most of the characters should be %-encoded 09:35:44 I mean in t=1, t could be percent-encoded 09:35:52 Yes Philip, but for the unreserve characters, you're typing too much by escapting them 09:35:53 unless we want to decide otherwise 09:36:11 s/unreserve/unreserved 09:36:17 fine, as long as we agree it's valid 09:36:49 t is in the unreserved set and thus rfc3986 recommends not encoding it 09:37:08 Point to RFC 3986 instead of RFC3339 in the above clarification 09:37:52 s/RFC3339/RFC3986 09:38:51 Raphael: Silvia, yes, but it also says that it does not matter if you encode it 09:38:58 6.2.2.2. Percent-Encoding Normalization <- explicitly talks about not encoding them 09:39:04 yes, I agree 09:39:16 s/the RFC3339/the RFC3986 09:40:01 rrsagent, draft minutes 09:40:01 I have made the request to generate http://www.w3.org/2010/03/08-mediafrag-minutes.html erik 09:41:31 Raphael: two remaining problems 09:42:25 ... 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 09:42:46 ... b) Should we keep the section 5.1.1 like that? (http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-name-value-components) 09:42:51 Jack: I'm very against 09:42:56 Yves: I'm very agains too 09:43:12 against which? 09:43:40 Section 5.1.1 09:43:46 Against using pseudo-code fragements in normative text, as in 5.1.1 09:44:02 I do not think we need to repeat what rfc3986 says about percent-encoding, so I am against a) 09:44:28 a) seems redundant 09:44:50 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) 09:44:51 b) otoh clarifies a lot - I don't mind the pseudo-code 09:44:54 why are you against it? 09:45:12 -mhausenblas 09:46:00 it clarifies what rfc3986 doesn't specify, but refers to a lot: what are name-value pairs in queries (and for us in fragments) 09:47:00 if someone can define processing of name-value pairs by some other method, fine 09:48:10 but I'm definitely against removing normative text without replacing it or leaving it "implicit" (i.e. undefined) 09:48:32 OK, back to a), we don't want to repeat but add some examples to clarify 09:48:55 Yves is editing live the spec, to remove the production rules with the quotes 09:49:15 ... and add some examples in section 4.2.5 09:49:39 ... examples of a temporal fragment with a + that is encoded, a track fragment with a '&' that is encoded, etc. 09:49:53 zakim, code? 09:49:53 the conference code is 3724 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), silvia 09:50:20 ... 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 09:50:29 now: b) 09:50:57 Jack: I have written an email why I think the pseudo-code is not good in the spec 09:51:28 + +28012aacc 09:51:36 zakim, aacc is me 09:51:36 +silvia; got it 09:53:23 section 4.2.3 has quotes in examles 09:54:05 and 4.2.4 09:55:43 Raphael: there is a problem with the section 5.1.1 09:56:05 Jack: the pseudo code is fuzzy, less valuable than written in a declarative language 09:56:17 ... the pseudo code will always make things less clear 09:58:43 mediasegment = namesegment / axissegment 09:58:44 axissegment = ( http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#timesegment / http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#spacesegment / http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#tracksegment ) 09:58:44 *( "&" ( http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#timesegment / http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#spacesegment / http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#tracksegment ) 09:58:53 Jack: I propose to replace this pseudo algorithm with just a few sentences that state we must first identify the key and values 09:59:02 ... follow what RFC is saying 09:59:36 Silvia: there are things you cannot write in ABNF 09:59:50 ... I prefer the text that Philip wrote 10:03:25 Raphael: the non agreement seems to be between specifying things in a declarative language vs procedural language 10:05:38 Silvia: you can rephrase this section, but I think we should NOT remove it 10:07:09 I would like to speak 10:07:32 erik has joined #mediafrag 10:08:00 Yes, Philip, 2 sec 10:08:24 zakim, mute me 10:08:24 silvia should now be muted 10:11:11 adding examples would be good 10:11:25 always helpful to clarify things for both programmers and users 10:12:33 -silvia 10:13:08 say "as transcribed in pseudo-code" instead of "as an example" 10:13:29 +silvia 10:13:32 zakim, mute me 10:13:32 silvia should now be muted 10:13:41 Yves: I propose to write the ABNF declarative language, and then, "as transcribed in pseudo code" and put the text of Philip^ 10:13:54 this is the only place that defines how to split name-value pairs, it is not clarifying 10:14:08 the spec can be restructured 10:14:24 you'll notice that there's no ABNF for &-=-separated lists 10:14:41 I wouldn't move it to another location - it's in the right place 10:14:47 Philip, splitting name/vsalue parise is described in the abnf... 10:14:52 s/parise/pairs 10:15:26 s/vsalue/value 10:15:27 See http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#fragment-structure 10:15:29 Yep, very first 2 productions 10:15:35 axissegment = ( timesegment / spacesegment / tracksegment ) 10:15:35 *( "&" ( timesegment / spacesegment / tracksegment ) 10:15:41 I removed that, someone put it back it seems 10:15:47 :-) 10:15:54 it doesn't make any sense to have both 10:16:14 I think it does, because that rule is rather unclear 10:16:18 OK, we make a smoking coffee break 10:16:28 we come back after 10:16:31 silvia, which rule is unclear, and why? 10:16:31 15 minutes break 10:16:41 ok 10:16:58 the rule in 4.1 is missing the percent-encoding 10:17:20 no, it's included in utf8string definition 10:17:30 the axissegment makes no sense, timesegment and others should be matched *after* percent-decoding 10:18:26 We do the break ... and I will phrase after my proposal of restructuring ... just wait 10:18:30 unless we have ABNF for percent-encoding + UTF-8 then there cannot be a complete ABNF at the URI level 10:18:44 there are two levels 10:19:02 and the way it is now, the dimension value is not %encoded 10:19:33 I have made the request to generate http://www.w3.org/2010/03/08-mediafrag-minutes.html raphael 10:19:36 ok, I'll be back in 15 10:19:37 yes, I removed the parts that didn't make sense, now that they are back the spec is just nonsense 10:19:40 Philip, that's about which terminals you have. Parsing vs. Lexing. 10:19:44 -silvia 10:20:22 close ACTION-150 10:20:22 ACTION-150 Summarize the discussion on the quotes in a mail or on the wiki closed 10:20:34 close ACTION-143 10:20:34 ACTION-143 Move 5.1.5 into a new section closed 10:21:07 close ACTION-144 10:21:07 ACTION-144 Move the section 5.1.1 to the top closed 10:21:11 jackjansen: ? What does that mean, in practice? 10:22:01 I have made the request to generate http://www.w3.org/2010/03/08-mediafrag-minutes.html raphael 10:23:39 - +0329331aaaa 10:23:53 -Guillaume 10:23:54 IA_MFWG(F2F)2:00AM has ended 10:23:55 Attendees were +0329331aaaa, mhausenblas, +2712841aabb, Guillaume, +28012aacc, silvia 10:24:17 ok, time to go home, zakim seems to think... :-) 10:25:16 IA_MFWG(F2F)2:00AM has now started 10:25:23 + +0329331aaaa 10:27:21 Yves: TCP/IP is not specified in declarative syntax, but has plenty of procedural sections in it, http://www.ietf.org/rfc/rfc793.txt 10:27:32 e.g. 10:27:33 SYN-RECEIVED STATE 10:27:33 If SND.UNA =< SEG.ACK =< SND.NXT then enter ESTABLISHED state 10:27:33 and continue processing. 10:27:35 If the segment acknowledgment is not acceptable, form a 10:27:37 reset segment, 10:27:41 10:27:45 and send it. 10:31:12 silvia, as I said earlier, I am ok to have both 10:32:10 it's kind of pointless to have this discussion without an alternative available for evaluation 10:33:17 the most important thing is that it is actually defined how to process name-value pairs 10:35:09 Yves, I was just curious about your statement and investigated :) 10:35:23 I agree, I think we should have both 10:35:40 the ABNF doesn't, but by having it the spec is simply self-contradictory about how to handle invalid name/value pairs 10:35:41 it will just be a challenge to make sure they actually express the same and don't contradict each other 10:36:00 I'd prefer to just have one representation, for sanity 10:36:24 the two current ones don't express the same thing, at all 10:36:35 so we need to fix that 10:36:41 indeed 10:36:52 Topic: 3. Structure of the spec 10:38:39 Raphael: from a high level view, I think we have various bits wrongly placed 10:38:50 ... Section 4 is about Media Fragment URI syntax 10:39:14 ... but Section 5 is about both how to process this syntax and how the protocol is working, soon with the headers syntax 10:39:51 ... 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 10:40:07 ... and the section 5 should be only about protocol and headers syntax 10:41:14 ... and I have also problems with the section 5.1.3 10:43:04 that refers only to section 5.1 ? 10:43:27 ... 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 10:43:29 I agree, 5.1.3 is a bit of a headache 10:43:49 what do you mean: "that refers only to section 5.1 ?" ? 10:44:02 I think the last paragraph in 5.1.3 needs its own section, but the rest doesn't 10:44:36 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? 10:44:58 Yves: following Frank suggestion, I would suggest having 4. Syntax; 5. Protocol; 6. Display 10:45:12 Raphael: not only silvia but mainly with 5.1 10:45:36 I don't see any new syntax anywhere else 10:45:38 no processing? 10:46:02 and move 6. Error handling to 7 ? 10:46:07 Raphael: Philip, 5. Protocol means processing the fragments and generate the headers 10:46:10 yes silvia 10:46:27 please no error handling :( 10:46:29 Silvia, new syntax elements soon to be introduced with ABNF versions of HTTP headers and HTTP responses 10:46:35 it's just "handling" 10:46:38 Why Philip ? 10:46:44 you handle errors and non-errors in the same way 10:46:59 those should stay with the protocol 10:47:01 it's much clearer to put it in the same section 10:47:22 I don't understand silvia, what should stay with the protocol? 10:47:30 they are, but finding a better name for the section is difficult - got a proposal? 10:47:48 silvia, how about "implementation guidelines"? 10:47:49 the syntax specification of the HTTP headers need to say with the protocol 10:47:57 Philip: you want to have the errors in the same section than the protocol? 10:48:08 this is what I said Silvia 10:48:08 not guidelines, normative, absolute rules 10:48:23 status of section (normative vs not) is independent 10:48:34 it's not actually about implementation guidelines - it's about how to process actual values 10:48:44 maybe it's the processing section that Philip is missing 10:48:51 can you phone in Silvia ... too many misunderstandings 10:49:48 raphael: good - just wanted to make sure case it's syntax, too :) 10:50:05 just two different communication threads :) 10:50:23 no no no 10:50:38 I would like to speak :) 10:50:46 zakim, code? 10:50:46 the conference code is 3724 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), silvia 10:52:06 raphael: no, there's no phone around 10:52:11 +silvia 10:52:17 zakim, mute me 10:52:17 silvia should now be muted 10:54:22 zakim, unmute me 10:54:22 silvia should no longer be muted 10:55:11 ok, I'll just write on IRC 10:57:59 Raphael: my proposal is section 4 = media fragment URI syntax (including the current sections 5.1.1 and 5.1.2) 10:58:38 ... section 5 = protocol handling, ABNF syntax of the HTTP headers, communication between servers and UA (current sections 5.2 and 5.3) 10:58:56 ... section 6 = display (current section 5.1.3) 10:59:06 I like semantics 10:59:07 ... section 7 = semantics + error handdling 10:59:19 I'd like to explain the different levels here 10:59:50 lowest level: URI fragment component (or URI query component) 10:59:57 Jack propose to switch sections 6 and 7 11:00:15 ... semantics first, then display / render 11:00:21 the syntax of this is *arbitrary* &-=-separated strings 11:00:22 I agree 11:00:47 the result of parsing this is a list of name-values 11:00:59 media fragments is modelled on top of this, not on the URI string 11:01:05 in my versions 11:01:17 fuly agree with philip 11:01:21 fully 11:01:24 so, the ABNF or whatever must reflect this 11:02:05 we can't say that the fragment component is composed from timesegment or whatever 11:02:20 Raphael: we all agree with you Philip, and suggest to add this in Section 4 11:02:32 i.e. the ABNF in 4.1 must be changed, or removed 11:02:56 zakim, mute me 11:02:56 silvia should now be muted 11:03:00 Philip, why? 11:03:06 Philip: we don't understand this: " we can't say that the fragment component is composed from timesegment or whatever" 11:03:33 jackjansen: because timeprefix and timeparam should be matched after splitting 11:03:40 and after percent-decoding and UTF8-decoding 11:03:56 i.e. they aren't on the same "level" 11:04:01 That's because urls are our main language. 11:04:16 if c++ was our main language it would be datastructures. 11:04:34 the current *segment syntaxes don't make this distinction 11:05:03 No, because it's semantics, not syntax. 11:05:23 Same would be true for c++ datastructure declarations... 11:06:10 are you missing the "timeprefix = timeparam" in 4.1 ? 11:07:09 (and same for all other examples, saying that it's foo = bar) 11:07:49 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 11:08:04 the grammar says that it's foo = bar then bar is percent encoded (see def of utf8string) 11:08:18