W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

RE: widget signature proposed change: ABNF

From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Date: Thu, 12 Mar 2009 21:23:42 +0100
To: Frederick Hirsch <Frederick.Hirsch@nokia.com>
CC: "Kapyaho Jere (Nokia-D-MSW/Tampere)" <Jere.Kapyaho@nokia.com>, ext Marcos Caceres <marcosc@opera.com>, WebApps WG <public-webapps@w3.org>
Message-ID: <FAA1D89C5BAF1142A74AF116630A9F2C0A26D78296@OBEEX01.obe.access-company.com>
Hi Frederick,

ABNF spec in ABNF (section B.1 of RFC5234) uses only hex base.
HTML5 uses only hex base.
Some other RFCs, e.g. RFC 3261 (SDP), use only hex base.
So I would stick only to hex base.

Of course, the base does not matter that much, it's just formalism.

Thanks.

Kind regards,
Marcin
________________________________________
From: Frederick Hirsch [Frederick.Hirsch@nokia.com]
Sent: Thursday, March 12, 2009 6:50 PM
To: Marcin Hanclik
Cc: Frederick Hirsch; Kapyaho Jere (Nokia-D-MSW/Tampere); ext Marcos Caceres; WebApps WG
Subject: Re: widget signature proposed change: ABNF

the ABNF spec used decimal for the character encoding examples and hex
for the digit range. I thought I should try to be consistent :).
Thanks for the fix on the range, there also a couple of typos in the
proposal text I can fix.

Shall I keep the characters in decimal and change the non-zero-range
to hex? That would match the RFC approach...

regards, Frederick

Frederick Hirsch
Nokia



On Mar 12, 2009, at 12:06 PM, ext Marcin Hanclik wrote:

> Hi Frederick,
>
> One line of the ABNF quoted below could be adjusted to match
> RFC5234: "3.4. Value Range Alternatives: %c##-##".
>
> non-zero-digit = %d049-%d057
>
> could be
>
> non-zero-digit = %d049-057
>
> Also I think that decimal encoding could be changed to hex encoding.
> Since the strings are already encoded, I think, hex has more compact
> representation and is used in ABNF spec itself.
>
> Thanks.
>
> Kind regards,
> Marcin
>
> Marcin Hanclik
> ACCESS Systems Europe GmbH
> Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
> Mobile: +49-163-8290-646
> E-Mail: marcin.hanclik@access-company.com
>
> -----Original Message-----
> From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org
> ] On Behalf Of Frederick Hirsch
> Sent: Thursday, March 12, 2009 4:40 PM
> To: Kapyaho Jere
> Cc: Frederick Hirsch; ext Marcos Caceres; WebApps WG
> Subject: widget signature proposed change: ABNF
>
> Here is a revised proposal to updated Widget Signature to use ABNF. We
> have to make adjustments since the strings are case sensitive now.
> Here are the change to the editors draft [1] required:
>
> 1) Change section 1.1, Notational conventions as follows:
>
> Replace
> This specification uses the following syntax to define filenames.
> Characters are appended to numbers to indicate cardinality: "?" (0 or
> 1) "*" (0 or more) "+" (1 or more)
>
> A range of values is indicated by brackets, .i.e [1-9] indicates a
> digit from the range 1 through 9 inclusive.
>
> Concatenated values are written next to each other, with strings
> indicated in quotes. Thus "signature" [1-9][0-9]* ".xml"means a string
> consisting of "signature" followed by a digit in the range 1-9
> inclusive, followed by zero or more digits in the range 0-9 inclusive,
> for example, "signature12.xml".
>
> with
> This specification uses the following ABNF [ABNF] syntax to define
> filenames. Rules are concatenated by being written next to each other
> and a rule prepended by * means zero or more. See he ABNF RFC for
> details.
>
> 2) Changes in the "Naming convention for a author signature:" in
> section 5.2 Author Signatures:
>
> The following ABNF [ABNF] rule defines the format of a author
> signature file name:
>
> Replace
>
> The reserved file name "author-signature.xml"
>
> with
>
> The reserved lower-case (case sensitive) file name "author-
> signature.xml", as defined by the following ABNF [ABNF] rule:
>
> author-signature-filename = %d097 %d117 %d116 %d104 %d111 %d114 %d045
> %d115 %d105 %d103 %d110   %d097 %d116 %d117 %d114 %d101 %d046 %d120
> %d109 %d108
>
> 3) Changes in the "Naming convention for a distributor signature:" in
> section 5.3 Distributor Signatures:
>
> 3a) Replace
>
> "signature" [1-9][0-9]* ".xml"
>
> with
>
> The following ABNF [ABNF] rule defines the format of a distributor
> signature file name:
>
> distributor-signature-filename = signature-string non-zero-digit
> *DIGIT  xml-suffix string
>
> signature-string = %d115 %d105 %d103 %d110 %d097 %d116 %d117 %d114
> %d101
>
> non-zero-digit = %d049-%d057
>
> xml-suffix-string =  %d046 %d120 %d109 %d108
>
> The signature-string rule defines the lower-case (case sensitive)
> string "signature" and the xml-suffix-string defines the lower-case
> (case sensitive) string ".xml". non-zero-digit defines a digit in the
> range 1-9. DIGIT is defined in RFC-5234 [ABNF] to mean a digit in the
> range 0-9.
>
> 3b) in first bullet, replace 'consisting of the string "signature"'
> with 'consisting of the lower-case string "signature"' and replace
> 'then ".xml", as stated by the BNF' with 'then the lower-case string
> ".xml", as stated by the ABNF'
>
> 3c) replace "BNF" with "ABNF" in the third bullet
>
> 4) Add reference to ABNF in references section, with source Jere
> noted:
>
> <dt><dfn id="abnf">[ABNF]</dfn></dt>
>   <dd>RFC 5234, <a href="http://www.ietf.org/rfc/
> rfc5234.txt"><cite>Augmented BNF
>                 for Syntax Specifications: <abbr title="Augmented
>                 Backus-Naur Form">ABNF</abbr></cite></a>. D. Crocker
> and P. Overell.
>   January 2008.</dd>
>
>
> Unless I hear otherwise by Monday, I will make this change to the
> editors draft. If you agree with the change please let me know.
>
> Thanks
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
> [1] http://dev.w3.org/2006/waf/widgets-digsig/
>
>
> On Mar 12, 2009, at 9:43 AM, Kapyaho Jere (Nokia-D-MSW/Tampere) wrote:
>
>> One (possibly minor) point regarding the filename rule:
>>
>> At least the Widgets 1.0 P&C spec uses ABNF (RFC 5234) and refers to
>> it, maybe this would be good also in the DigSig spec?
>>
>> The rule expressed in ABNF would be something like:
>>
>>>
>> signature-filename = "signature" non-zero-digit *DIGIT  ".xml"
>> non-zero-digit = %x31-39
>>
>> Here, DIGIT is a prefabricated rule defined in RFC 5234. This rule
>> says that in between the strings there must be at least one non-zero
>> digit, followed by zero or more "normal" digits.
>>
>> The normative reference for ABNF would be (grabbed from the P&C
>> spec):
>>
>> <dt><dfn id="abnf">[ABNF]</dfn></dt>
>>  <dd>RFC 5234, <a href="http://www.ietf.org/rfc/
>> rfc5234.txt"><cite>Augmented BNF
>>                for Syntax Specifications: <abbr title="Augmented
>>                Backus-Naur Form">ABNF</abbr></cite></a>. D.
>> Crocker  and P. Overell.
>>  January 2008.</dd>
>>
>> --Jere
>>
>> On 9.3.2009 22.51, "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com
>>> wrote:
>>
>> I updated section 4 to correspond to  this:
>>
>> "If the signatures list is not empty, sort the list of signatures by
>> the file name field in ascending numerical order (e.g.signature1.xml
>> followed by signature2.xml followed by signature3.xml etc)."
>>
>>
>> regards, Frederick
>>
>> Frederick Hirsch
>> Nokia
>>
>>
>>
>> On Mar 6, 2009, at 10:07 AM, ext Marcos Caceres wrote:
>>
>>> Hi Frederick,
>>>
>>> On 3/6/09 3:59 PM, Frederick Hirsch wrote:
>>>> I've updated the widget signature document distributor file naming
>>>> convention to the following after discussing this with Josh (thanks
>>>> Josh):
>>>>
>>>> Naming convention for a distributor signature:
>>>>   |"signature" [1-9][0-9]* ".xml"|
>>>>
>>>>       *
>>>>
>>>>         Each distributor signature /MUST/ have a name consisting
>> of
>>>>         the string "signature" followed by a digit in the range
>> 1-9
>>>>         inclusive, followed by zero or more digits in the range
>> 0-9
>>>>         inclusive and then ".xml", as stated by the BNF. An
>>>> example is
>>>>         "signature20.xml".
>>>>
>>>>       *
>>>>
>>>>         Leading zeros are disallowed in the numbers.
>>>>
>>>>       *
>>>>
>>>>         Any file name that does not match this BNF /MUST/ be
>>>> ignored.
>>>>         Thus a file named "signature01.xml" will be ignored. A
>>>> warning
>>>>         /MAY/ be generated.
>>>>
>>>>       *
>>>>
>>>>         There is no requirement that all the signature file names
>>>> form
>>>>         a contiguous set of numeric values.
>>>>
>>>>       *
>>>>
>>>>         These signatures /MUST/ be sorted numerically based on the
>>>>         numeric portion of the name. Thus signature2.xml preceeds
>>>>         signature11.xml, for example.
>>>>
>>>>
>>>> See draft
>>>> http://dev.w3.org/2006/waf/widgets-digsig/#distributor-signatures
>>>>
>>>> I also updated the notation section, changed the code format to be
>>>> italic (without color), and updated the body style to not be quite
>>>> so large.
>>>>
>>>> Please indicate any comment or corrections on the list.
>>>>
>>>
>>> The changes look good to me! thank you.
>>>
>>> Kind regards,
>>> Marcos
>>
>>
>>
>
>
>
> ________________________________________
>
> 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.
Received on Thursday, 12 March 2009 20:24:59 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:30 GMT