Re: [widgets] Content-type sniffing and file extension to MIME mapping
2008/12/10 Laurens Holst [EMAIL PROTECTED]: Marcos Caceres schreef: Seems that there is still too much incompatibility to suggest application/xml support across Widget user agents. I think we should just stick with text/html. If authors want to use application/xml, then they can use content src=somefile type=application/xml / and hope for the best :) XHTML is a W3C standard that's been Recommended status for many years and has plenty of implementations (except for Internet Explorer, at this time). This should be more than enough to warrant inclusion in the list of MIME type mappings. I'm against using the application/xml type for XHTML by the way. A more specific MIME type is available and it has its use in certain occasions (e.g. for content negotiation, to determine whether the UA is requesting a human-readable XHTML version or a site-specific machine-readable XML version). XML is a transmission format that a lot of different formats make use of, however each format using XML is still a format on its own and should have its own MIME type. E.g. application/xhtml+xml should not be confused with application/rdf+xml, even though both could be served as application/xml. The content element is defined here: http://dev.w3.org/2006/waf/widgets/#the-content I'm not sure if any widget engines support application/xhtml+xml. I think just adding it because it's a rec is not a valid argument. As Hixie argued, it may be supported by some UA's but it's not well understood by developers [1]. Implementation of HTML5 is well underway in many browsers, which supersedes XHTML in lots of ways. I think just mandating support for text/html is sufficient for widgets. Adding application/xhtml+xml just adds more baggage to widgets and no implementer has requested its support. However, if implementers request it, then we will consider adding it. Kind regards, Marcos [1] http://hixie.ch/advocacy/xhtml. -- Marcos Caceres http://datadriven.com.au
[widgets] Packaging Configuration 1.0 pre-CfC comments
Hi Marcos, finally I got the chance to read the Widgets 1.0 Packaging Configuration spec. Great work there; please accept some comments based on the Editor's Draft 7 December 2008 version, up at [1]. 5.3 Zip Relative Paths The ABNF needs some polishing: - Rule names like cp437 vs. cp437-chars, utf8-range vs. utf8-chars, ascii-range vs. ascii-chars. - ABNF rules are case-insensitive as per RFC 5234 [2]; does this affect the Language-Tag rule in any way? - delimiter should be %x2F or just / for readability - In cp437-chars, should say %x80-FF (and no semicolon) - s/is define in/is defined in/ 5.4 Reserved characters - Minor issue with the table of reserved characters: the Unicode code points column would be better labeled Unicode character and be made the first column. The CP437 column is redundant, IMHO. The column Character representation could be just Representation or Representative glyph. - Are filenames of ZIP entries case-sensitive or not? The ZIP spec does not seem to say (or I missed it), but the PC spec has several recommendations about case. 6.4 Content localization - Note that since localized folders now must reside in the root of the widget package, they pollute the root namespace, and it is possible to (more or less accidentally) have a normal folder whose name is a valid BCP47 language tag. In essence, all valid BCP47 language tags would have to be treated as reserved. Should the localized folders instead be placed one level down from the root, inside folder 'X', where 'X' is a suitable reserved name like 'resources'? - If there ever is a case of the WUA having to iterate all the localized folders, I think it's going to be difficult or impossible to find them all. We had this problem in JSR 238 [3], and ended up having a metadata entry that lists the supported locales. It can be generated by a widget packaging tool. Not ideal, but beats a combinatorial explosion... :) Or maybe you envision that the lang-priority-list removes the need to iterate? 6.5 Start file and Default Start Files See Step X for instructions of how to find the default start file. -- here X should probably be 9. 8. Steps for Processing a Widget Resource Step 6 - Determine the base folder and widget locale - Algorithm step 2.d.i.2 seems to be missing something (Let base folder .). - Algorithm step 2.d.ii refers to this step 2.4. References - ZIP file spec: seems to be revised from time to time, would it be good to freeze the reference to a particular version? - Might want to fill in the HTTP, URI, ABNF etc. references before formal publication. BTW, did you already get someone to volunteer to do it? I'll help if not too late. - Make all the URIs also links (like BCP47). Hope this helps. Best regards, Jere [1] http://dev.w3.org/2006/waf/widgets/ [2] http://tools.ietf.org/rfc/rfc5234.txt [3] http://jcp.org/en/jsr/detail?id=238 -- Jere Käpyaho ([EMAIL PROTECTED]) Specialist, Developer Platforms Standardization Devices RD, Nokia Corporation
Re: [widgets] Content-type sniffing and file extension to MIME mapping
On Tue, Dec 9, 2008 at 12:42 PM, Marcos Caceres [EMAIL PROTECTED] wrote: If authors want to use application/xml, then they can use content src=somefile type=application/xml / and hope for the best :) On Wed, Dec 10, 2008 at 12:06 AM, Adam Barth [EMAIL PROTECTED] wrote: I haven't been following the widget discussion very closely, so I apologize if this issue is understood already, but, in general, being able to coerce an arbitrary URL to application/xml is a big security problem. Can you point me to where the content tag is defined? this seems pointless. you're packaging your own widget. which means you control somefile and the manifest. you shouldn't be able to have somefile point *outside* widget, which means you were responsible for packaging somefile. if you're worried about a scanner, that's a problem the scanners will have to manage anyway, as this is a new thing which is going to have a slightly different profile than a web page. the wua isn't being tricked anywhere, it's doing as instructed and would know it was doing so. i can certainly serve a file named something as type application/xml over http, the difference here is that you're an archive (zip) which doesn't encode mime types and has no server.
Re: [widgets] Content-type sniffing and file extension to MIME mapping
On Tue, Dec 9, 2008 at 10:06 PM, Adam Barth [EMAIL PROTECTED] wrote: On Tue, Dec 9, 2008 at 12:42 PM, Marcos Caceres [EMAIL PROTECTED] wrote: If authors want to use application/xml, then they can use content src=somefile type=application/xml / and hope for the best :) I haven't been following the widget discussion very closely, so I apologize if this issue is understood already, but, in general, being able to coerce an arbitrary URL to application/xml is a big security problem. Can you point me to where the content tag is defined? The content element is defined here: http://dev.w3.org/2006/waf/widgets/#the-content Would certainly appreciate more details about the security threat. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [XHR] blocking httpOnly cookies
On Mon, 20 Oct 2008 17:04:24 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: In bug 380418 [1] we have decided to completely block access to the Set-Cookie header through XHR. This seems like the safest way to prevent httpOnly cookies from leaking in to javascript. In addition it seems good to block access to the raw network protocol used for security and can contain user credentials. There is a risk that this will break sites since we are blocking things that used to work. However the number of legitimate uses seems pretty small (I can't think of any) and the win is high (blocking httpOnly cookies reliably as well as possible future cookie expansions) The way the blocking works is that the getResponseHeader and getAllResponseHeaders functions behave as if Set-Cookie and Set-Cookie2 was not sent by the server. / Jonas [1] https://bugzilla.mozilla.org/show_bug.cgi?id=380418 This is the exact same approach Opera has been following for a while. I have made this a requirement in the XMLHttpRequest specifications (the draft versions, of course). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [XMLHttpRequest]HttpOnly cookies visibility in XMLHttpRequest
On Mon, 07 Jul 2008 23:24:03 +0200, eric bing [EMAIL PROTECTED] wrote: Thanks Bjoern for laying out the reasoning here. I'm going to make one more tilt at the windmill... What I'm hearing from you and Anne is that you don't disagree with the basic principle that XHR should not be able to be able to access HttpOnly cookies. But rather that this spec is not the correct place to address this issue - because (I hope I'm restating these correctly) 1) It belongs in the (sadly non-existent) spec of cookies 2) It should be obvious to implementers 3) We can't list out all security implications - for various reasons we'll miss some and weaken all security I have to respectfully disagree with 2 - this was fixed for plain javascript access to cookies, but the XHR portions were left out in in IE6 and Firefox 2. For background on the Firefox fix - check out https://bugzilla.mozilla.org/show_bug.cgi?id=380418 It seems that the solution to this specific issue is in fact completely oblivious to httponly. That is, Cookie and Cookie2 can no longer be set as request headers and Set-Cookie and Set-Cookie2 cannot be read as response headers. I'm therefore planning on removing the httponly cookie note as it is no longer necessary. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [widgets] Content-type sniffing and file extension to MIME mapping
Marcos Caceres schreef: I'm not sure if any widget engines support application/xhtml+xml. I do not know your definition of ‘widget engine’, but Opera, Safari, Firefox all support application/xhtml+xml (and Prince XML too, but I don’t suppose that would be used for widgets :)). And last I checked, Internet Explorer doesn’t implement this specification anyway (neither do the other browsers, for that matter). Also, I am *not* requesting that implementors of this specification be required to support application/xhtml+xml, I am merely requesting that the .xhtml to application/xhtml+xml mapping is predefined, so that browsers which optionally *do* support it can be served content without having to explicitly create a MIME type mapping file. I think just adding it because it's a rec is not a valid argument. As Hixie argued, it may be supported by some UA's but it's not well understood by developers [1]. That document talks about sending XHTML as text/html, not XHTML in general. Also, it is the opinion of one person, one that I can only partially agree with. For example, one of the argument is based on the premise that HTML4 is SGML, something which we all know is not true. Also, actually HTML5 does support exactly this (even though Hixie doesn’t like it, last I heard). Implementation of HTML5 is well underway in many browsers, which supersedes XHTML in lots of ways. XHTML, that is the XML serialisation of HTML, is built-in HTML5. HTML5 does not supersede XHTML, it integrates it [1][2]. The HTML5 specification defines the application/xhtml+xml MIME type. In fact, the specification’s subtitle is “A vocabulary and associated APIs for HTML and XHTML”. You are aware of this, right? I think just mandating support for text/html is sufficient for widgets. Adding application/xhtml+xml just adds more baggage to widgets and no implementer has requested its support. I might as well just repeat myself (again): I am not requesting that XHTML support be added as a requirement for widget engines. I am just requesting that the mapping be predefined. However, if implementers request it, then we will consider adding it. It would be good if the people deciding on this had an informed opinion, instead of making assumptions and just following the ‘HTML good, XML bad’ mantra that seems to be popular among certain groups lately, and not hide behind statements like ‘if implementors request it’. I don’t understand the resistance against adding a MIME type mapping for a well-known and supported standard. As I explained before, adding a MIME type mapping does not actually mandate support for that MIME type in any way, if it does not support it the browser can respond as it normally would when being served application/xhtml+xml by an HTTP server. As I said before, I hope you are not using this specification to perpetuate your personal preference for text/html. HTML5 supports both XML and HTML serialisations, and the Widgets specification should not do otherwise. ~Laurens [1] http://dev.w3.org/html5/spec/Overview.html#relationship-to-html-4.01-and-dom2-html [2] http://dev.w3.org/html5/spec/Overview.html#html-vs-xhtml -- Note: New email address! Please update your address book. ~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~ Laurens Holst, student, university of Utrecht, the Netherlands Website: www.grauw.nl. Backbase employee; www.backbase.com begin:vcard fn:Laurens Holst n:Holst;Laurens email;internet:[EMAIL PROTECTED] tel;cell:(+31) 06-41765048 version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: [XHR2] progress events dispatch rate
On Tue, 25 Nov 2008 21:18:44 +0100, Olli Pettay [EMAIL PROTECTED] wrote: Hi Anne, it would be great to get the 50ms to the draft spec ;) Fixed! (Been away for a while, hence the delay.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [widgets] Content-type sniffing and file extension to MIME mapping
Marcos Caceres schreef: Seems that there is still too much incompatibility to suggest application/xml support across Widget user agents. I think we should just stick with text/html. If authors want to use application/xml, then they can use content src=somefile type=application/xml / and hope for the best :) XHTML is a W3C standard that’s been Recommended status for many years and has plenty of implementations (except for Internet Explorer, at this time). This should be more than enough to warrant inclusion in the list of MIME type mappings. I’m against using the application/xml type for XHTML by the way. A more specific MIME type is available and it has its use in certain occasions (e.g. for content negotiation, to determine whether the UA is requesting a human-readable XHTML version or a site-specific machine-readable XML version). XML is a transmission format that a lot of different formats make use of, however each format using XML is still a format on its own and should have its own MIME type. E.g. application/xhtml+xml should not be confused with application/rdf+xml, even though both could be served as application/xml. ~Laurens -- Note: New email address! Please update your address book. ~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~ Laurens Holst, student, university of Utrecht, the Netherlands Website: www.grauw.nl. Backbase employee; www.backbase.com begin:vcard fn:Laurens Holst n:Holst;Laurens email;internet:[EMAIL PROTECTED] tel;cell:(+31) 06-41765048 version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: [XMLHttpRequest]HttpOnly cookies visibility in XMLHttpRequest
Anne, Thanks for your response and thought over this matter. Perhaps we could make a compromise and change: Apart from requirements affecting security made throughout this specification implementations */may/, at their discretion*, not expose certain headers, such as headers containing HttpOnly cookies. to Apart from requirements affecting security made throughout this specification implementations /*should */not expose certain headers, such as headers containing HttpOnly cookies. Since implementors of XHR need to address this issue to truly honor the security benefits of HTTPOnly, I would really like to see this in the current XHR spec. Thanks for entertaining this conversation, Jim Manico Aspect Security On Mon, 07 Jul 2008 23:24:03 +0200, eric bing [EMAIL PROTECTED] wrote: Thanks Bjoern for laying out the reasoning here. I'm going to make one more tilt at the windmill... What I'm hearing from you and Anne is that you don't disagree with the basic principle that XHR should not be able to be able to access HttpOnly cookies. But rather that this spec is not the correct place to address this issue - because (I hope I'm restating these correctly) 1) It belongs in the (sadly non-existent) spec of cookies 2) It should be obvious to implementers 3) We can't list out all security implications - for various reasons we'll miss some and weaken all security I have to respectfully disagree with 2 - this was fixed for plain javascript access to cookies, but the XHR portions were left out in in IE6 and Firefox 2. For background on the Firefox fix - check out https://bugzilla.mozilla.org/show_bug.cgi?id=380418 It seems that the solution to this specific issue is in fact completely oblivious to httponly. That is, Cookie and Cookie2 can no longer be set as request headers and Set-Cookie and Set-Cookie2 cannot be read as response headers. I'm therefore planning on removing the httponly cookie note as it is no longer necessary.
Re: [widgets] Content-type sniffing and file extension to MIME mapping
Hi Laurens, 2008/12/10 Laurens Holst [EMAIL PROTECTED]: Marcos Caceres schreef: I'm not sure if any widget engines support application/xhtml+xml. I do not know your definition of 'widget engine', but Opera, Safari, Firefox all support application/xhtml+xml (and Prince XML too, but I don't suppose that would be used for widgets :)). And last I checked, Internet Explorer doesn't implement this specification anyway (neither do the other browsers, for that matter). Please read the spec for a definition of a widget user agent (widget engine). Also, I am *not* requesting that implementors of this specification be required to support application/xhtml+xml, I am merely requesting that the .xhtml to application/xhtml+xml mapping is predefined, so that browsers which optionally *do* support it can be served content without having to explicitly create a MIME type mapping file. This encourages fragmentation. We don't want developers developing in XHTML at all if those widgets are not going to work interoperably on HTML-only widget engines (and yes, those exists! a reference implementation of this specification is being developed on pocket IE). We don't forbid xhtml (hence the content element's type attribute.) I think just adding it because it's a rec is not a valid argument. As Hixie argued, it may be supported by some UA's but it's not well understood by developers [1]. That document talks about sending XHTML as text/html, not XHTML in general. I'm not going to be drawn into citations war about this. This isn't about that. Also, it is the opinion of one person, one that I can only partially agree with. For example, one of the argument is based on the premise that HTML4 is SGML, something which we all know is not true. And I quote, HTML 4 is an SGML application conforming to International Standard ISO 8879 -- Standard Generalized Markup Language [ISO8879]. The HTML4.01 spec says it's so. Browsers didn't follow the spec. By specification, HTML4.01 *is* SGML. If you deny this fact, then your notion of HTML has not been formally defined anywhere. Also, actually HTML5 does support exactly this (even though Hixie doesn't like it, last I heard). I'm not sure what this is. I also don't particularly care about what Hixie's position is on things. I'm capable of drawing my own conclusions from whatever evidence is available. Hixie's document, although advocating a position, formulates are logical argument backed by testable/verifiable evidence. Implementation of HTML5 is well underway in many browsers, which supersedes XHTML in lots of ways. XHTML, that is the XML serialisation of HTML, is built-in HTML5. HTML5 does not supersede XHTML, it integrates it [1][2]. The HTML5 specification defines the application/xhtml+xml MIME type. In fact, the specification's subtitle is A vocabulary and associated APIs for HTML and XHTML. You are aware of this, right? right. I think just mandating support for text/html is sufficient for widgets. Adding application/xhtml+xml just adds more baggage to widgets and no implementer has requested its support. I might as well just repeat myself (again): I am not requesting that XHTML support be added as a requirement for widget engines. I am just requesting that the mapping be predefined. If it's purely optional, it's not necessary to have it in the Widget spec. The mapping to a file extension It's already defined here: http://www.rfc-editor.org/rfc/rfc3236.txt However, if implementers request it, then we will consider adding it. It would be good if the people deciding on this had an informed opinion, instead of making assumptions and just following the 'HTML good, XML bad' mantra that seems to be popular among certain groups lately, and not hide behind statements like 'if implementors request it'. I don't appreciate you insulting me or other members of the working group by implying we are ignorant. I'm not hiding behind anything: as editor, my role is to represent the interests of members and the public in the spec. Also, I never said anything about good/bad aspects of HTML or XML. I don't understand the resistance against adding a MIME type mapping for a well-known and supported standard. As I explained before, adding a MIME type mapping does not actually mandate support for that MIME type in any way, if it does not support it the browser can respond as it normally would when being served application/xhtml+xml by an HTTP server. Why should XHTML get preferential treatment? By that logic I should also add RDF or whatever other obscure implemented specification supported by browsers. As I said before, I hope you are not using this specification to perpetuate your personal preference for text/html. HTML5 supports both XML and HTML serialisations, and the Widgets specification should not do otherwise. I don't have a personal preference (I think they both suck). When I worked as a proffesional Web developer, I
Re: [XHR] Error flag
On Sun, 07 Dec 2008 23:14:34 +0100, Kartikaya Gupta [EMAIL PROTECTED] wrote: The editor's draft of the XHR spec doesn't say when to clear the error flag. Based on experimentation I'm guessing it's supposed to be cleared in step 21 of the open() algorithm. Is this correct? Yeah. Though it should probably also be cleared the moment you invoke send(). Also, will the IDL be updated to reflect exceptions thrown from the various methods and property accessors? This may already be on the to-do list, but I thought I'd mention it in case it wasn't. I was not planning on doing this. It makes the IDL unreadable in my opinion and I believe it is not required in Web IDL (and if it is we should change that :-)). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [XHR] Error flag
On Wed, 10 Dec 2008 16:04:08 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: On Sun, 07 Dec 2008 23:14:34 +0100, Kartikaya Gupta [EMAIL PROTECTED] wrote: The editor's draft of the XHR spec doesn't say when to clear the error flag. Based on experimentation I'm guessing it's supposed to be cleared in step 21 of the open() algorithm. Is this correct? Yeah. Though it should probably also be cleared the moment you invoke send(). Actually, clearing it when you invoke send() should be enough. Made that change to the editor drafts. (I saw you made this comment way earlier in May as well as a private comment, sorry for taking so long to get to it.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [widgets] Packaging Configuration 1.0 pre-CfC comments
Hi Jere, On Wed, Dec 10, 2008 at 12:47 PM, Jere Kapyaho [EMAIL PROTECTED] wrote: Hi Marcos, finally I got the chance to read the Widgets 1.0 Packaging Configuration spec. Great work there; please accept some comments based on the Editor's Draft 7 December 2008 version, up at [1]. 5.3 Zip Relative Paths The ABNF needs some polishing: - Rule names like cp437 vs. cp437-chars, utf8-range vs. utf8-chars, ascii-range vs. ascii-chars. Fixed. - ABNF rules are case-insensitive as per RFC 5234 [2]; does this affect the Language-Tag rule in any way? No, they are also case insensitive. - delimiter should be %x2F or just / for readability used /. - In cp437-chars, should say %x80-FF (and no semicolon) fixed. - s/is define in/is defined in/ fixed. 5.4 Reserved characters - Minor issue with the table of reserved characters: the Unicode code points Fixed. column would be better labeled Unicode character and be made the first column. Fixed. The CP437 column is redundant, IMHO. Right. dropped it. The column Character representation could be just Representation or Representative glyph. Used Representative glyph. - Are filenames of ZIP entries case-sensitive or not? The ZIP spec does not seem to say (or I missed it), but the PC spec has several recommendations about case. I think they are case insensitive. So, if you have two file entries with the same file name (say a and A) inside a zip file, upon decompression, one will override each other. This is also a problem on operating systems that are case insensitive. 6.4 Content localization - Note that since localized folders now must reside in the root of the widget package, they pollute the root namespace, and it is possible to (more or less accidentally) have a normal folder whose name is a valid BCP47 language tag. In essence, all valid BCP47 language tags would have to be treated as reserved. Should the localized folders instead be placed one level down from the root, inside folder 'X', where 'X' is a suitable reserved name like 'resources'? I don't think this is necessary. We should maybe add a conformance checker behavior to warn authors about this. - If there ever is a case of the WUA having to iterate all the localized folders, I think it's going to be difficult or impossible to find them all. Is this a problem with the way the algorithm in the spec is written? or is this a problem with with BCP47? We had this problem in JSR 238 [3], and ended up having a metadata entry that lists the supported locales. It can be generated by a widget packaging tool. Not ideal, but beats a combinatorial explosion... :) Or maybe you envision that the lang-priority-list removes the need to iterate? If the problem is with strangely formed langauge tags, I wonder if conformance checkers will help there? 6.5 Start file and Default Start Files See Step X for instructions of how to find the default start file. -- here X should probably be 9. Fixed. 8. Steps for Processing a Widget Resource Step 6 - Determine the base folder and widget locale - Algorithm step 2.d.i.2 seems to be missing something (Let base folder .). Ok, it's now Let base folder be the name of the folder that matched the current range. - Algorithm step 2.d.ii refers to this step 2.4. fixed. Should have been 2.d References - ZIP file spec: seems to be revised from time to time, would it be good to freeze the reference to a particular version? Agreed. We will probably freeze on 6.3.1. - Might want to fill in the HTTP, URI, ABNF etc. references before formal publication. BTW, did you already get someone to volunteer to do it? I'll help if not too late. I haven't had anyone volunteer (though Mohamed Zergaoui sent in some comments regarding what needed fixing[1]). I would _really_ appreciate any help you can give me! - Make all the URIs also links (like BCP47). Will do. Kind regards, Marcos [1] http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0436.html -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Content-type sniffing and file extension to MIME mapping
On Wed, Dec 10, 2008 at 2:55 AM, Marcos Caceres [EMAIL PROTECTED] wrote: The content element is defined here: http://dev.w3.org/2006/waf/widgets/#the-content Would certainly appreciate more details about the security threat. Thanks for the pointer. As timeless points out, this doesn't look like a security issue in this context because the content can be included only from within the widget. In other settings, you have to be careful about sites that let users upload content. For example, many sites let users upload images. If you take an HTTP response from one of these sites and override its Content-Type, you might be tricked into running the attacker's HTML in the honest site's security context. Adam
RE: ZIP-based packages and URI references into them ODF proposal
Ian Hickson wrote: I believe that the difference between these two states is the difference between looking at specifications as definitions of protocol, format, language vs implementation functional specifications. The former gives us a neat set of orthogonal specifications that seem quite simple, but in practice, what we need for quality software is the latter. Do you mean that to be true in general, or are you just saying that you think it's the case more often than some others in the community believe it to be. Question: do you believe that the specification for ASCII would best be done as in implementation functional specification? That suggests that, rather than publishing, say, a table of integers and their mapping to characters, it would be better to write a specification for a piece of code that consumes ASCII, to explain what to do if it finds a character that isn't ASCII (perhaps because it accepts 16 bit values, but considers them valid only if the high order byte is 0)? Maybe a separate specification or chapters for producers of ASCII? Don't get me wrong: you're discussing an important tradeoff and I'm not suggesting that you're wrong in all cases (you're clearly not) or even that you're necessarily wrong in the case of HTML 5 (I think I've expressed before that I think we would do well to have BOTH a specification for the language and for the common implementation.) I do think that your statement as quoted above goes much further than I believe is true, or perhaps than you intended. I also think that languages like XML are in many ways similar to ASCII with respect to purposes of this discussion. HTML is less clearcut in this respect, because of the Javascript capability. Cheers. Noah -- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 --
RE: ZIP-based packages and URI references into them ODF proposal
On Wed, 10 Dec 2008 [EMAIL PROTECTED] wrote: Question: do you believe that the specification for ASCII would best be done as in implementation functional specification? That suggests that, rather than publishing, say, a table of integers and their mapping to characters, it would be better to write a specification for a piece of code that consumes ASCII, to explain what to do if it finds a character that isn't ASCII (perhaps because it accepts 16 bit values, but considers them valid only if the high order byte is 0)? Maybe a separate specification or chapters for producers of ASCII? The way that IE and Firefox handle bytes with values greater than 0x7F when a file is labelled as being encoded as ASCII differs -- IE ignores the 8th bit, and only looks at the first seven bits, whereas Firefox treats bytes in the range 0x80 to 0xFF as being encoded as Windows-1252. This leads to security bugs, wherein the two browsers might treat the two strings differently (in particular, what looks like script/script to IE might look like something quite different to Firefox). I believe the ASCII specification should have defined how to convert any random byte stream into characters, including bytes that aren't in the range 0-127. That it didn't means that every language that allows ASCII has to define how to handle it, which is an abstraction violation, and results in different specs having different rules. In many cases, the layers above ASCII didn't define this, and we've ended up with very real security problems, such as the example above. Now in the case of ASCII doing this would be trivial -- e.g. just say that all bytes that aren't in the range 0x00 - 0x7F must be treated as 0x3F, and say that producers must not use bytes that aren't in the table. But yes, it should be in the ASCII spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [XHR] Error flag
On Wed, 10 Dec 2008 16:28:25 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: Actually, clearing it when you invoke send() should be enough. Made that change to the editor drafts. I see the change in the XHR2 draft, but not the XHR draft. Also, will the IDL be updated to reflect exceptions thrown from the various methods and property accessors? This may already be on the to-do list, but I thought I'd mention it in case it wasn't. I was not planning on doing this. It makes the IDL unreadable in my opinion and I believe it is not required in Web IDL (and if it is we should change that :-)). It does hamper readability somewhat, but it also increases usefulness. I guess the question is whether the IDL is informative or normative. If it's normative, then I think the exceptions should be added for correctness. The [Null] and [Undefined] extended attributes are much worse for readability, IMO. And on the topic of IDL, I assume you're sticking with your plan of not specifying a module/namespace? Cheers, kats
Re: [widgets] Packaging Configuration 1.0 pre-CfC comments
Hi Marcos, On 10.12.2008 18.40, ext Marcos Caceres [EMAIL PROTECTED] wrote: - If there ever is a case of the WUA having to iterate all the localized folders, I think it's going to be difficult or impossible to find them all. Is this a problem with the way the algorithm in the spec is written? or is this a problem with with BCP47? Neither, really. This could turn out to be mostly a non-issue specifically because BCP47 was designed to be parsed with just formal understanding. All subtags can be identified by length and position, so you just need to iterate all the folder names and check if they could be formally valid language tags. This could still give you false positives (directories with a name that is a valid language tag, but which are not 'localized folders'), which is why I suggested placing them one level down from the root. You still need to check, but not all top-level dirs. But if you think this is rare enough not to worry about, then I'll probably agree. :) --Jere
