[widgets] LCWD#3 comments (3)
Hi Marcos, It seems I found another problem in RFC. 7.4 valid-MIME-type = type / subtype *(; parameter) and we refer to RFC2045 that says: [1] content := Content-Type : type / subtype *(; parameter) Then, RFC2045 gives examples like: [2] Content-type: text/plain; charset=us-ascii The problem is about the spaces. As for me [2] does not match [1]. Anyway, it seems I can live with that issue, since it seems to affect more than just PC :). Therefore, for the purposes of my LC comments, with 99.99% certainty I will be satisfied with your response. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
RE: [widgets] LCWD#3 comments (3)
Hi Marcos, All, For the purposes of my LC comments, I am satisfied with the text in PC as it is in section 7.4. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcin Hanclik Sent: Friday, November 20, 2009 12:36 PM To: WebApps WG Subject: [widgets] LCWD#3 comments (3) Hi Marcos, It seems I found another problem in RFC. 7.4 valid-MIME-type = type / subtype *(; parameter) and we refer to RFC2045 that says: [1] content := Content-Type : type / subtype *(; parameter) Then, RFC2045 gives examples like: [2] Content-type: text/plain; charset=us-ascii The problem is about the spaces. As for me [2] does not match [1]. Anyway, it seems I can live with that issue, since it seems to affect more than just PC :). Therefore, for the purposes of my LC comments, with 99.99% certainty I will be satisfied with your response. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you. Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [widgets] LCWD#3 comments (3)
On Fri, Nov 20, 2009 at 11:36 AM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Marcos, It seems I found another problem in RFC. 7.4 valid-MIME-type = type / subtype *(; parameter) and we refer to RFC2045 that says: [1] content := Content-Type : type / subtype *(; parameter) Then, RFC2045 gives examples like: [2] Content-type: text/plain; charset=us-ascii The problem is about the spaces. As for me [2] does not match [1]. I don't know, maybe parameter allows spaces? but yeah, that first space after Content-type: seems non-conforming. Anyway, it seems I can live with that issue, since it seems to affect more than just PC J. Me too. Lets get some implementation feedback. Therefore, for the purposes of my LC comments, with 99.99% certainty I will be satisfied with your response. Yippy! :D -- Marcos Caceres http://datadriven.com.au
Re: [widgets] LCWD#3 comments (3)
On Nov 20, 2009, at 8:24 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Marcos, I don't know, maybe parameter allows spaces? but yeah, that first space after Content-type: seems non-conforming. RFC2045: parameter := attribute = value attribute := token ; Matching of attributes ; is ALWAYS case-insensitive. value := token / quoted-string token := 1*any (US-ASCII) CHAR except SPACE, CTLs, or tspecials tspecials := ( / ) / / / @ / , / ; / : / \ / / / [ / ] / ? / = ; Must be in quoted-string, ; to use within parameter values token excludes SPACE. We have to live with that, I think. RFC4288: There is no defined syntax for parameter values. However, RFC2045 says also: By itself, however, this grammar is incomplete. and refers to RFC822 that in turn talks about folding and unfolding (white-spaces, multiple lines etc.). It seems to be a legacy stuff from the mail industry, therefore we will probably not fix it here. LOL, this stuff truly is turtles all the way down! :) Thanks, Marcin From: marcosscace...@gmail.com [marcosscace...@gmail.com] On Behalf Of Marcos Caceres [marc...@opera.com] Sent: Friday, November 20, 2009 7:31 PM To: Marcin Hanclik Cc: WebApps WG Subject: Re: [widgets] LCWD#3 comments (3) On Fri, Nov 20, 2009 at 11:36 AM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Marcos, It seems I found another problem in RFC. 7.4 valid-MIME-type = type / subtype *(; parameter) and we refer to RFC2045 that says: [1] content := Content-Type : type / subtype *(; parameter) Then, RFC2045 gives examples like: [2] Content-type: text/plain; charset=us-ascii The problem is about the spaces. As for me [2] does not match [1]. I don't know, maybe parameter allows spaces? but yeah, that first space after Content-type: seems non-conforming. Anyway, it seems I can live with that issue, since it seems to affect more than just PC J. Me too. Lets get some implementation feedback. Therefore, for the purposes of my LC comments, with 99.99% certainty I will be satisfied with your response. Yippy! :D -- Marcos Caceres http://datadriven.com.au Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
RE: [widgets] LCWD#3 comments (3)
Hi Marcos, All, Just a couple of comments about the consistency of the W3C specifications: XHR (whose editor is also from Opera) says: The term [...] valid MIME type [are] ..is.. defined by the HTML 5 specification. [HTML5] HTML5 says: A string is a valid MIME type if it matches the media-type rule defined in section 3.7 Media Types of RFC 2616. [HTTP] RFC2616 [1]: media-type = type / subtype *( ; parameter ) type = token subtype= token So the same term of the valid MIME type once refers to RFC2046 in PC, another time to RFC2616 in XHR (via HTML5). The above comments are not to be interpreted as part of my PC LCWD#3 review. Thanks, Marcin [1] http://tools.ietf.org/html/rfc2616#section-3.7 From: Marcos Caceres [marc...@opera.com] Sent: Friday, November 20, 2009 9:38 PM To: Marcin Hanclik Cc: WebApps WG Subject: Re: [widgets] LCWD#3 comments (3) On Nov 20, 2009, at 8:24 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Marcos, I don't know, maybe parameter allows spaces? but yeah, that first space after Content-type: seems non-conforming. RFC2045: parameter := attribute = value attribute := token ; Matching of attributes ; is ALWAYS case-insensitive. value := token / quoted-string token := 1*any (US-ASCII) CHAR except SPACE, CTLs, or tspecials tspecials := ( / ) / / / @ / , / ; / : / \ / / / [ / ] / ? / = ; Must be in quoted-string, ; to use within parameter values token excludes SPACE. We have to live with that, I think. RFC4288: There is no defined syntax for parameter values. However, RFC2045 says also: By itself, however, this grammar is incomplete. and refers to RFC822 that in turn talks about folding and unfolding (white-spaces, multiple lines etc.). It seems to be a legacy stuff from the mail industry, therefore we will probably not fix it here. LOL, this stuff truly is turtles all the way down! :) Thanks, Marcin From: marcosscace...@gmail.com [marcosscace...@gmail.com] On Behalf Of Marcos Caceres [marc...@opera.com] Sent: Friday, November 20, 2009 7:31 PM To: Marcin Hanclik Cc: WebApps WG Subject: Re: [widgets] LCWD#3 comments (3) On Fri, Nov 20, 2009 at 11:36 AM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Marcos, It seems I found another problem in RFC. 7.4 valid-MIME-type = type / subtype *(; parameter) and we refer to RFC2045 that says: [1] content := Content-Type : type / subtype *(; parameter) Then, RFC2045 gives examples like: [2] Content-type: text/plain; charset=us-ascii The problem is about the spaces. As for me [2] does not match [1]. I don't know, maybe parameter allows spaces? but yeah, that first space after Content-type: seems non-conforming. Anyway, it seems I can live with that issue, since it seems to affect more than just PC J. Me too. Lets get some implementation feedback. Therefore, for the purposes of my LC comments, with 99.99% certainty I will be satisfied with your response. Yippy! :D -- Marcos Caceres http://datadriven.com.au Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you. Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
