<div dir="ltr"><div>John,</div><div><br></div><div>A few comments on your comparison note. In </div><div>"<span style="font-family:Calibri,sans-serif;font-size:11pt;line-height:115%">Differences between RFC 2616 and RFC 7231".</span></div><div><span style="font-family:Calibri,sans-serif;font-size:11pt;line-height:115%"><br></span></div><div>> token</div><div>> No differences</div><div><br></div><div>Exactly.</div><div> </div><div>> qdtext</div><div>> </div><div>> RFC 2616 includes LF (octet 10 / %x0A), CR (octet 13 / %x0D),</div><div>> \ (octet 92 / %x5C). RFC 7231 disallows these characters.</div><div><br></div><div>%x5C should certainly be disallowed, since it starts a </div><div>quoted pair.</div><div><br></div><div>> quoted-pair</div><div>> </div><div>> RFC 2616 allows any character in the standard ASCII range</div><div>> (octets 0-127). RFC 7231 disallows the range octets 0-31</div><div>> except for octet 9 (HTAB).</div><div><br></div><div>Furthermore, RFC 7231 disallows 7F but allows 80-FF.</div><div><br></div><div>Regards,</div><div>Makoto</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-09 16:07 GMT+09:00 MURATA Makoto <span dir="ltr"><<a href="mailto:eb2m-mrt@asahi-net.or.jp" target="_blank">eb2m-mrt@asahi-net.or.jp</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">John,<div><br></div><div>Thank you very much for this summary.</div><div><br></div></span><div><b>Re: <span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:14.6666669845581px">Whether we are OK with the differences introduced by RFC 7231</span></b></div><div><br></div><div>If there are no strong reasons not to use RFC 7231, we should use </div><div>it. Moreover, our regular expression already adopts some new features </div><div>of RFC 7231.</div><div><font color="#1f497d" face="Calibri, sans-serif"><span style="font-size:14.6666669845581px"><br></span></font></div><div><b>Re: <span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">Whether we should rewrite the XSD regex pattern by translating </span></b></div><span class=""><div><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"><b>the RFC 7231 media-type definition (as Part 2 originally did with RFC 2616)</b></span></div><div><br></div></span><div><font color="#1f497d" face="Calibri, sans-serif"><span style="font-size:14.6666660308838px">One possibility is to drop the regexp and to introduce prose that </span></font></div><div><font color="#1f497d" face="Calibri, sans-serif"><span style="font-size:14.6666660308838px">references RFC 7231 normatively</span></font><span style="font-size:14.6666660308838px;color:rgb(31,73,125);font-family:Calibri,sans-serif">. Our life will be easier, since we </span></div><div><span style="font-size:14.6666660308838px;color:rgb(31,73,125);font-family:Calibri,sans-serif">are not obliged to ensure </span><span style="font-size:14.6666660308838px;color:rgb(31,73,125);font-family:Calibri,sans-serif">equivalence of our regexp and RFC 7231. </span></div><div><span style="font-size:14.6666660308838px;color:rgb(31,73,125);font-family:Calibri,sans-serif">People are unlikely to validate </span><span style="font-size:14.6666660308838px;color:rgb(31,73,125);font-family:Calibri,sans-serif">the value of @ContentType, and </span></div><div><span style="font-size:14.6666660308838px;color:rgb(31,73,125);font-family:Calibri,sans-serif">might not notice errors. But the </span><span style="font-size:14.6666660308838px;color:rgb(31,73,125);font-family:Calibri,sans-serif">value of this attribute is almost </span></div><div><span style="font-size:14.6666660308838px;color:rgb(31,73,125);font-family:Calibri,sans-serif">always a token followed </span><span style="font-size:14.6666660308838px;color:rgb(31,73,125);font-family:Calibri,sans-serif">by "/" followed by a token.</span></div><div><span style="font-size:14.6666660308838px;color:rgb(31,73,125);font-family:Calibri,sans-serif"><br></span></div><div><span style="font-size:14.6666660308838px;color:rgb(31,73,125);font-family:Calibri,sans-serif">Another possibility is to create a regexp that faithfully captures </span></div><div><span style="font-size:14.6666660308838px;color:rgb(31,73,125);font-family:Calibri,sans-serif">RFC 7231. Our life will be harder and the regular expression </span></div><div><span style="font-size:14.6666660308838px;color:rgb(31,73,125);font-family:Calibri,sans-serif">will not be easy to read (even if it is better than the present </span></div><div><span style="font-size:14.6666660308838px;color:rgb(31,73,125);font-family:Calibri,sans-serif">regexp). But syntactical errors will be captured by XML </span></div><div><span style="font-size:14.6666660308838px;color:rgb(31,73,125);font-family:Calibri,sans-serif">validators.</span></div><div><u></u></div><div><font color="#1f497d" face="Calibri, sans-serif"><span style="font-size:14.6666669845581px"><br></span></font></div><div><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:14.6666669845581px"><b>Re: Whether we should then simplify the regex in some partial or </b></span></div><span class=""><div><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:14.6666669845581px"><b>extreme way, within the limits of what XSD and RNG allow</b></span></div><div><font color="#1f497d" face="Calibri, sans-serif"><span style="font-size:14.6666669845581px"><br></span></font></div></span><div><font color="#1f497d" face="Calibri, sans-serif"><span style="font-size:14.6666669845581px">Unnecessary complexity is harmful, but </span></font><span style="font-size:14.6666669845581px;color:rgb(31,73,125);font-family:Calibri,sans-serif">should create a loose </span></div><div><span style="font-size:14.6666669845581px;color:rgb(31,73,125);font-family:Calibri,sans-serif">regexp only for readability? I do not like this option, but </span></div><div><span style="font-size:14.6666669845581px;color:rgb(31,73,125);font-family:Calibri,sans-serif">it might be a practical solution.</span></div><div><span style="font-size:14.6666669845581px;color:rgb(31,73,125);font-family:Calibri,sans-serif"><br></span></div><div><span style="font-size:14.6666669845581px;color:rgb(31,73,125);font-family:Calibri,sans-serif">Regards,</span></div><div><span style="font-size:14.6666669845581px;color:rgb(31,73,125);font-family:Calibri,sans-serif">Makoto</span></div><div><div class="h5"><div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-17 8:11 GMT+09:00 John Haug <span dir="ltr"><<a href="mailto:johnhaug@exchange.microsoft.com" target="_blank">johnhaug@exchange.microsoft.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Annex D (and E) have a very lengthy regular expression restricting the allowed values for ST_ContentType. We looked at this in depth during the meetings in Bellevue,
resulting from Murata-san’s December 2014 e-mail “Which RFC(s) for media type should we refer to?” and February 2015 e-mail “My proposals: content type and media ypest”. There were some corrections to make and no clear answer as to what the regex is intended
for.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">After the meetings, I took a similar look at the regex, compared it to RFC 2616 (the regex is intended to match the RFC), compared RFCs 2616 and 7231 and documented
everything in the attached. (This includes a fix to the error Murata-san noted.) The e-mail discussion is included below.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">1. The questions I initially posed are still open:<u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Symbol;color:rgb(31,73,125)"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Whether we are OK with the differences introduced by RFC 7231<u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Symbol;color:rgb(31,73,125)"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Whether we should rewrite the XSD regex pattern by translating the RFC 7231 media-type definition (as Part 2 originally did with RFC 2616)<u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Symbol;color:rgb(31,73,125)"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Whether we should then simplify the regex in some partial or extreme way, within the limits of what XSD and RNG allow<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">2. Francis’ question about \s+ in what I call Y still needs examination.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">For further discussion among the larger group!<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">John<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> <a href="mailto:eb2mmrt@gmail.com" target="_blank">eb2mmrt@gmail.com</a> [mailto:<a href="mailto:eb2mmrt@gmail.com" target="_blank">eb2mmrt@gmail.com</a>]
<b>On Behalf Of </b>MURATA Makoto<br>
<b>Sent:</b> Thursday, March 12, 2015 10:15 PM<br>
<b>To:</b> John Haug<br>
<b>Cc:</b> Francis Cave; Arms, Caroline; Rex Jaeschke; Chris Rae; Gareth Horton; Alex Brown; Rich McLain; MURATA Makoto (FAMILY Given)<br>
<b>Subject:</b> Re: PLEASE PROOF: Day 3 Draft Minutes from the Seattle Meeting of SC 34/WG4<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">John,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">First, let us correctly understand what we have right now. I do not <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">think this can be done without using some macro (or XML entities).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Then, compare our (faithfully rewritten) regexp and RFC 2161 and
<br>
then compare it and RFC 7231.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">John, please incorporate my change (as part of the first step) and <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">post your document to the WG4 mailing list.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Regards,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Makoto<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">2015-03-11 8:51 GMT+09:00 John Haug <<a href="mailto:johnhaug@exchange.microsoft.com" target="_blank">johnhaug@exchange.microsoft.com</a>>:<u></u><u></u></p>
<blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">(I’ve combined the split replies from Francis and Murata-san.)</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Re: Francis:</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">My intent here wasn’t to propose a simplification to include in Part 2. I just wanted to reverse engineer what Part 2 currently has and compare it to
the RFCs. I therefore did no reduction of the content. Leaving it as is showed that Part 2 contained a quite literal translation of the RFC’s BNF to XSD regex syntax. Your comment about \s in X is true, but I left it that way intentionally as part of the
reverse engineering.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Regarding \s+ in Y, I think they again literally translated qdtext, but perhaps not quite right? Maybe \s+ should have been appended after the last
item in the first bracketed expression in Y?</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Consolas">Y: ([\p{IsLatin-1Supplement}\p{IsBasicLatin}-[\p{Cc}"]]|\s+)</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Consolas">qdtext = <any TEXT except <">><br>
TEXT = <any OCTET except CTLs, but including LWS><br>
OCTET = <any 8-bit sequence of data><br>
CTL = <any US-ASCII control character (octets 0 - 31) and DEL (127)><br>
LWS = [CRLF] 1*( SP | HT ) ; linear white space<br>
CRLF = CR LF</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">OCTET limits us to 0-255. CTLs removes 0-31 and 127. LWS adds back in 9, 10, 13 (32 already allowed). qdtext removes 34.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">>
</span>Note that U+00A0 is in the Latin-1 supplement. I'm not sure whether this character should be explicitly excluded from X. It can presumably be included in Y, as this in a quoted string.<u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">I might be missing something. The content represented by X doesn’t include anything above 127 (0x7F).</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Re: Murata-san:</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Ah, I think you’re right. I believe my omitting that one set of parentheses makes the * apply only to the [\p{IsBasicLatin}] and not also to the \\.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Given that I’m not trying to propose a simplification of the regex, or even that we should do so, assuming I’m correct above, shall I make Murata-san’s
edit to the doc and send it to the WG 4 list purely as investigation into what Part 2 currently says?</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">John</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="color:rgb(31,73,125)">
<hr size="2" width="100%" align="center">
</span></div>
<p class="MsoNormal"><b>From:</b>
<a href="mailto:eb2mmrt@gmail.com" target="_blank">eb2mmrt@gmail.com</a> [mailto:<a href="mailto:eb2mmrt@gmail.com" target="_blank">eb2mmrt@gmail.com</a>]
<b>On Behalf Of </b>MURATA Makoto<br>
<b>Sent:</b> Saturday, February 28, 2015 11:51 PM<br>
<b>To:</b> John Haug<br>
<b>Cc:</b> Arms, Caroline; Rex Jaeschke; Chris Rae; Francis Cave; Gareth Horton; Alex Brown; Rich McLain<br>
<b>Subject:</b> Re: PLEASE PROOF: Day 3 Draft Minutes from the Seattle Meeting of SC 34/WG4<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">John,<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Nice work!<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">I think that <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">("(([\p{IsLatin-1Supplement}\p{IsBasicLatin}-[\p{Cc}"]]|\s+)|(<a>\\[\p{IsBasicLatin}])*)"</a>;)<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">cannot be simplified to <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">("(Y |
<a>\\[\p{IsBasicLatin}]*)"</a>;)<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Rather, it should become<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">("(Y|(<a>\\[\p{IsBasicLatin}]))*"</a>;)<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Regards,<u></u><u></u></p>
<p class="MsoNormal">Makoto<u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<div>
<div style="border-style:solid none none;border-top-color:rgb(225,225,225);border-top-width:1pt;padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Francis Cave [mailto:<a href="mailto:francis@franciscave.com" target="_blank">francis@franciscave.com</a>]
<br>
<b>Sent:</b> Saturday, February 28, 2015 4:37 AM<br>
<b>To:</b> John Haug; Arms, Caroline; 'Rex Jaeschke'; Makoto Murata; Chris Rae; Gareth Horton; Alex Brown; Rich McLain<br>
<b>Subject:</b> Re: PLEASE PROOF: Day 3 Draft Minutes from the Seattle Meeting of SC 34/WG4<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">John<br>
<br>
Good job! I just have one niggle, which is with your use of \s in the definitions of both X and Y. The problem is that \s includes \t \n and \r, all of which are in \p{Cc}. The meaning of \s is not SPACE, but 'white space', where this includes all Unicode space
characters (i.e. including U+0020 and U+00A0, but also presumably some other space characters), and also includes control characters TAB, CR and LF.
<br>
<br>
In X this isn't so critical, because you're excluding \s, but that means that there is redundancy in the expression, because \t \n and \r are already excluded by excluding \p{Cc}.
<br>
<br>
In Y the problem is more serious, because you are including \s+ as an alternative choice to the rest of the expression. Effectively this allows \t \n and \r in Y expressions that are white space only.<br>
<br>
I suspect that the only white space character that should be allowed in Y, is U+0020, i.e. the regular SPACE character. This would be the same as SP in the ABNF in RFC 7231.<br>
<br>
Note that U+00A0 is in the Latin-1 supplement. I'm not sure whether this character should be explicitly excluded from X. It can presumably be included in Y, as this in a quoted string.<br>
<br>
Here is a list of Unicode spaces: <a href="https://www.cs.tut.fi/~jkorpela/chars/spaces.html" target="_blank">
https://www.cs.tut.fi/~jkorpela/chars/spaces.html</a>. As this isn't an official list, I cannot be certain that this is accurate. My assumption is that \s includes all these.<br>
<br>
I am assuming that \p{Cc} includes control characters in the Unicode range U+0080 to U+009F, as well as the control characters in the basic ASCII range.<br>
<br>
Kind regards,<br>
<br>
Francis<br>
<br>
<br>
<br>
<br>
On 28/02/2015 00:31, John Haug wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal"><span style="color:rgb(68,84,106)">I’ve attached what I came up with, which should fully explain the issue and be step-by-step enough to make it easier to ensure there are no typos/errors.
Please review this before it goes out to all of WG 4. Once we’re sure there are no typos/errors, we can either include it in the minutes of the Bellevue meeting or I can just attach it to a reply to Murata-san’s last e-mail on the subject to the WG 4 list.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(68,84,106)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(68,84,106)">Pursuant to the revision, we will need to decide:</span><u></u><u></u></p>
<p><span style="font-family:Symbol">·</span><span style="font-size:7pt">
</span><span style="color:rgb(68,84,106)">Whether we are OK with the differences introduced by RFC 7231</span><u></u><u></u></p>
<p><span style="font-family:Symbol">·</span><span style="font-size:7pt">
</span><span style="color:rgb(68,84,106)">Whether we should rewrite the XSD regex pattern by translating the RFC 7231 media-type definition (as Part 2 originally did with RFC 2616)</span><u></u><u></u></p>
<p><span style="font-family:Symbol">·</span><span style="font-size:7pt">
</span><span style="color:rgb(68,84,106)">Whether we should then simplify the regex in some partial or extreme way, within the limits of what XSD and RNG allow</span><u></u><u></u></p>
<p class="MsoNormal"><a name="14c9d019a7a48520_14c24dc62c8a80d4_14c061a20dd5e194__MailEndCompose"><span style="color:rgb(68,84,106)"> </span></a><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(68,84,106)">Thanks,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(68,84,106)">John</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(68,84,106)"> </span><u></u><u></u></p>
<div>
<div style="border-style:solid none none;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> John Haug
<br>
<b>Sent:</b> Thursday, February 26, 2015 3:08 PM<br>
<b>To:</b> 'Arms, Caroline'; 'Rex Jaeschke'; Makoto Murata; Chris Rae; Francis Cave; Gareth Horton; Alex Brown; Rich McLain<br>
<b>Subject:</b> RE: PLEASE PROOF: Day 3 Draft Minutes from the Seattle Meeting of SC 34/WG4</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(68,84,106)">Re: the ST_ContentType regex: I am nearly done with a lengthy explanatory break-it-down tutorial document that shows the derivation step by step! Thanks
much to Murata-san for all the initial investigation and to him and Francis for talking through it on the screen yesterday at (painful) length.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(68,84,106)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(68,84,106)">The short version is that the huge 6-line regex in Part 2 is a literal translation of RFC 2616’s definition of media-type into an XSD pattern. I have
that part done and am working on the differences between RFC 2616 and RFC 7231 (and friends). I think it’s reasonable to change the Part 2 normative reference to 7231 (and friends by reference from 7231) since it has obsoleted 2616. But we ought to understand
and discuss the differences before making a concrete decision on that.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(68,84,106)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(68,84,106)">John</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(68,84,106)"> </span><u></u><u></u></p>
<div>
<div style="border-style:solid none none;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> Arms, Caroline [<a href="mailto:caar@loc.gov" target="_blank">mailto:caar@loc.gov</a>]
<br>
<b>Sent:</b> Thursday, February 26, 2015 2:56 PM<br>
<b>To:</b> 'Rex Jaeschke'; Makoto Murata; John Haug; Chris Rae; Francis Cave; Gareth Horton; Alex Brown; Rich McLain<br>
<b>Subject:</b> RE: PLEASE PROOF: Day 3 Draft Minutes from the Seattle Meeting of SC 34/WG4</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Rex,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">I think you should get a sentence or two from Murata-san or someone else about what needs to be done to get the regular expression for the ContentTypes
schema fixed – the third point in Murata-san’s message. I wasn’t able to hear that discussion clearly enough. I believe it was decided that some testing might be needed – but maybe that was only discussed but not decided.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> Caroline
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<div>
<div style="border-style:solid none none;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> Rex Jaeschke [<a href="mailto:rex@RexJaeschke.com" target="_blank">mailto:rex@RexJaeschke.com</a>]
<br>
<b>Sent:</b> Thursday, February 26, 2015 2:51 PM<br>
<b>To:</b> Makoto Murata; Arms, Caroline; John Haug; Chris Rae; Francis Cave; Gareth Horton; Alex Brown; Rich McLain<br>
<b>Subject:</b> PLEASE PROOF: Day 3 Draft Minutes from the Seattle Meeting of SC 34/WG4</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Attached are the draft minutes as at the end of the meeting.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Once I get some words on XAdES, I’ll send out the final draft to WG4 and TC45.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">I’ll update the DR log to reflect the minutes, in the next hour.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Rex</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
</blockquote>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <u></u><u></u></p>
<div>
<p class="MsoNormal"><br>
Praying for the victims of the Japan Tohoku earthquake<br>
<br>
Makoto<u></u><u></u></p>
</div>
</div>
</div>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br>Praying for the victims of the Japan Tohoku earthquake<br><br>Makoto</div>
</div></div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><br>Praying for the victims of the Japan Tohoku earthquake<br><br>Makoto</div>
</div>