June 2005 - sg16-avd - lists.packetizer.com

Re: H.248.1 Editing meeting
by Christian Groves 29 Jun '05

29 Jun '05

Hello Kevin, I have added some additional comments to the Alcatel comments in: ftp3.itu.int/avc-site/Incoming/ TD9 Updated Draft_h248.1v3 Clean_comments_Ericsson.zip As part of the review I went through my IG style comments in: ftp3.itu.int/avc-site/Incoming/ DC-xxx_H_248_1v3_Corrections_Clarifications_v3.zip I've marked up the items in green that haven't been included (no. 1,4,5,6,10). I can understand why 5 was not included. What is the reasoning behind 1,4,6,10? I don't think there is any new functionality??? Regards, Christian Albrecht.Schwarz(a)alcatel.de wrote: > Thanks Simao for assistance and clarifications! > > Actually I was using Windows Commander 4.51 as FTP client, and the > Netscape > browser only as cross-check "tool". > I was unsure because the file wasn't visible in the Commander. > > I've the same opinion as you with regard to the previous settings. > Meaning, > I may live with a period of uncertainity ("time from unconfirmed, hiding > uploading in Incoming till visibility in working directory"). > > Thanks again, > Albrecht > > > > > > <simao.campos@it > > u.int> To: Albrecht > SCHWARZ/DE/ALCATEL@ALCATEL, <kboyle(a)nortel.com> > cc: > <itu-sg16(a)external.cisco.com> > 28.06.2005 14:52 Subject: RE: H.248.1 > Editing meeting > > > > > > > Dear Albrecht, > > to upload comments to the Incoming directory, please use an FTP client > using the current guest username and password, instead of a web browser > (http://...) > > Best, > Simao > > >>-----Original Message----- >>From: Albrecht.Schwarz(a)alcatel.de >>[mailto:Albrecht.Schwarz@alcatel.de] >>Sent: 28 June 2005 13:17 >>To: Kevin Boyle >>Cc: itu-sg16(a)external.cisco.com >>Subject: Re: H.248.1 Editing meeting >> >> >>Kevin, thanks for your effort! >> >>Can imagine that you can't see the text anymore;-) >>Nevertheless; I'd like to propose some more editorial change >>proposals, almost all originating from types or space characters. >> >>Unfortunately I'm unable to upload my comments on the avc site: >> >>http://ftp3.itu.int/av-arch/avc-site/Incoming/ >>"You don't have permission to access >>/av-arch/avc-site/Incoming/ on this server." >> >> >>That's why I'll send the file >>TD9 Updated Draft_h248.1v3 Clean_commentsALCATEL.doc >> >>in a separate email to Kevin directly. >> >>Regards >>Albrecht >> >> >> >> >> >> >> >> >> "Kevin Boyle" >> >> <kboyle(a)nortel.c To: >>itu-sg16(a)external.cisco.com >> >> om> cc: >> >> Subject: >>H.248.1 Editing meeting >> >> 27.06.2005 11:36 >> >> >> >> >> >> >> >>All, >> >> >>I have uploaded two versions of the working document to the >>Incoming folder on the FTP site -- one with change marks as >>TD8R1 and one without as TD9. >>These reflect all the changes through all 5 weeks thus far. >>The only change I have not made was the addition of Notify to >>the profile template. >>There seems to be a problem with the FTP site, in that it >>will not list the contents of the folders. Once that problem >>has been resolved, I will update the document to include it. >> >> >>Please look over the document. I have been over the spec in >>great detail making the capitalization uniform as best I can. >> If you see any cases that do not align with the rest of the >>document, please let me know. Also, have a look across the >>document for the changes you suggested. In some cases, I >>took the suggestion for change and altered the wording a >>little differently than suggested. In some cases there were >>multiple changes to the same place suggested, and I did the >>best I could to merge the suggestions. >>Hopefully I have captured the intent of all. >> >> >>I hope you all find my many hours of work satisfactory. As a >>reminder, this is the week to suggest any further edits. The >>document that emerges at the end of this week will be the >>input document to Geneva. >> >> >>Kevin >> >> >> > > >

1 0

Re: H.248.1 Editing meeting
by Yangbo Lin 29 Jun '05

29 Jun '05

Thanks for your effort! However I have to bother you again because I cannot find the changes my suggested in the updated document TD8R1 or TD9. I think that maybe you have not noticed the reviewing comments from me to the week 5 section because I had uploaded it by mail directly and no FTP. Please refer to the document which is already in the directory and consider the reviewing comments. Thank you! ----- Original Message ----- From: Kevin Boyle <mailto:kboyle@nortel.com> To: itu-sg16(a)external.cisco.com Sent: Monday, June 27, 2005 5:36 PM Subject: H.248.1 Editing meeting All, I have uploaded two versions of the working document to the Incoming folder on the FTP site -- one with change marks as TD8R1 and one without as TD9. These reflect all the changes through all 5 weeks thus far. The only change I have not made was the addition of Notify to the profile template. There seems to be a problem with the FTP site, in that it will not list the contents of the folders. Once that problem has been resolved, I will update the document to include it. Please look over the document. I have been over the spec in great detail making the capitalization uniform as best I can. If you see any cases that do not align with the rest of the document, please let me know. Also, have a look across the document for the changes you suggested. In some cases, I took the suggestion for change and altered the wording a little differently than suggested. In some cases there were multiple changes to the same place suggested, and I did the best I could to merge the suggestions. Hopefully I have captured the intent of all. I hope you all find my many hours of work satisfactory. As a reminder, this is the week to suggest any further edits. The document that emerges at the end of this week will be the input document to Geneva. Kevin

1 0

Preparation for the SG16 Q.25 meeting: H.235.x drafts uploaded
by Euchner Martin 28 Jun '05

28 Jun '05

Dear security experts, In preparation of the forthcoming SG16 meeting Q.25 session, I've uploaded all draft H.235.x subseries Recommendations (H.235.0, .1, .2, .3, .4, .6 and .7) under my own editorship to the working docs directory at http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/ <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/> The documents encompass the current draft Recommendation texts (H.235.x) as well as the cover sheets (TD-WP2-AAA) where the recent changes are recorded. Also provided are the A.5 qualification drafts (TD-PLEN-aaa) rectifying the external normative references. I've also uploaded a TD-WP2-xxx with a proposed draft corrigendum2 for H.235v3. All drafts are subjects to change. Two major open issues are worth noting: * In H.235.4, I've removed contents of clause 10 "Procedure DRC2 - Interdomain Environment"; added editor note that clause is FFS pending contributions for the unification approach. * In H.235.6, Clause 7.8 holds an {Editor's note: Fix the problem of Diffie-Hellman key exchange in conjunction with H.450.x supplementary services. } which deserves fixing. If no solution is found, add a note that there is problem, while the solution of the problem is left FFS. Both areas are of particular importance where I particularly solicit contributions (deadline for submission July 14th). I appreciate very much your review and feedback of the drafts. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | COM GC PS 3 mailto:Martin.Euchner@siemens.com <mailto:Martin.Euchner@siemens.com> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ <http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/> | D-81359 Muenchen Internet: http://www.siemens.de/ <http://www.siemens.de/> | __________________ | Germany -----------------------------------------------------------------------

1 0

RE: H.248.1 Editing meeting
by Albrecht.Schwarz＠alcatel.de 28 Jun '05

28 Jun '05

Thanks Simao for assistance and clarifications! Actually I was using Windows Commander 4.51 as FTP client, and the Netscape browser only as cross-check "tool". I was unsure because the file wasn't visible in the Commander. I've the same opinion as you with regard to the previous settings. Meaning, I may live with a period of uncertainity ("time from unconfirmed, hiding uploading in Incoming till visibility in working directory"). Thanks again, Albrecht <simao.campos@it u.int> To: Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, <kboyle(a)nortel.com> cc: <itu-sg16(a)external.cisco.com> 28.06.2005 14:52 Subject: RE: H.248.1 Editing meeting Dear Albrecht, to upload comments to the Incoming directory, please use an FTP client using the current guest username and password, instead of a web browser (http://...) Best, Simao > -----Original Message----- > From: Albrecht.Schwarz(a)alcatel.de > [mailto:Albrecht.Schwarz@alcatel.de] > Sent: 28 June 2005 13:17 > To: Kevin Boyle > Cc: itu-sg16(a)external.cisco.com > Subject: Re: H.248.1 Editing meeting > > > Kevin, thanks for your effort! > > Can imagine that you can't see the text anymore;-) > Nevertheless; I'd like to propose some more editorial change > proposals, almost all originating from types or space characters. > > Unfortunately I'm unable to upload my comments on the avc site: > > http://ftp3.itu.int/av-arch/avc-site/Incoming/ > "You don't have permission to access > /av-arch/avc-site/Incoming/ on this server." > > > That's why I'll send the file > TD9 Updated Draft_h248.1v3 Clean_commentsALCATEL.doc > > in a separate email to Kevin directly. > > Regards > Albrecht > > > > > > > > > "Kevin Boyle" > > <kboyle(a)nortel.c To: > itu-sg16(a)external.cisco.com > > om> cc: > > Subject: > H.248.1 Editing meeting > > 27.06.2005 11:36 > > > > > > > > All, > > > I have uploaded two versions of the working document to the > Incoming folder on the FTP site -- one with change marks as > TD8R1 and one without as TD9. > These reflect all the changes through all 5 weeks thus far. > The only change I have not made was the addition of Notify to > the profile template. > There seems to be a problem with the FTP site, in that it > will not list the contents of the folders. Once that problem > has been resolved, I will update the document to include it. > > > Please look over the document. I have been over the spec in > great detail making the capitalization uniform as best I can. > If you see any cases that do not align with the rest of the > document, please let me know. Also, have a look across the > document for the changes you suggested. In some cases, I > took the suggestion for change and altered the wording a > little differently than suggested. In some cases there were > multiple changes to the same place suggested, and I did the > best I could to merge the suggestions. > Hopefully I have captured the intent of all. > > > I hope you all find my many hours of work satisfactory. As a > reminder, this is the week to suggest any further edits. The > document that emerges at the end of this week will be the > input document to Geneva. > > > Kevin > > >

1 0

RE: H.248.1 Editing meeting
by simao.campos＠ITU.INT 28 Jun '05

28 Jun '05

Dear Albrecht, to upload comments to the Incoming directory, please use an FTP client using the current guest username and password, instead of a web browser (http://...) Best, Simao > -----Original Message----- > From: Albrecht.Schwarz(a)alcatel.de > [mailto:Albrecht.Schwarz@alcatel.de] > Sent: 28 June 2005 13:17 > To: Kevin Boyle > Cc: itu-sg16(a)external.cisco.com > Subject: Re: H.248.1 Editing meeting > > > Kevin, thanks for your effort! > > Can imagine that you can't see the text anymore;-) > Nevertheless; I'd like to propose some more editorial change > proposals, almost all originating from types or space characters. > > Unfortunately I'm unable to upload my comments on the avc site: > > http://ftp3.itu.int/av-arch/avc-site/Incoming/ > "You don't have permission to access > /av-arch/avc-site/Incoming/ on this server." > > > That's why I'll send the file > TD9 Updated Draft_h248.1v3 Clean_commentsALCATEL.doc > > in a separate email to Kevin directly. > > Regards > Albrecht > > > > > > > > > "Kevin Boyle" > > <kboyle(a)nortel.c To: > itu-sg16(a)external.cisco.com > > om> cc: > > Subject: > H.248.1 Editing meeting > > 27.06.2005 11:36 > > > > > > > > All, > > > I have uploaded two versions of the working document to the > Incoming folder on the FTP site -- one with change marks as > TD8R1 and one without as TD9. > These reflect all the changes through all 5 weeks thus far. > The only change I have not made was the addition of Notify to > the profile template. > There seems to be a problem with the FTP site, in that it > will not list the contents of the folders. Once that problem > has been resolved, I will update the document to include it. > > > Please look over the document. I have been over the spec in > great detail making the capitalization uniform as best I can. > If you see any cases that do not align with the rest of the > document, please let me know. Also, have a look across the > document for the changes you suggested. In some cases, I > took the suggestion for change and altered the wording a > little differently than suggested. In some cases there were > multiple changes to the same place suggested, and I did the > best I could to merge the suggestions. > Hopefully I have captured the intent of all. > > > I hope you all find my many hours of work satisfactory. As a > reminder, this is the week to suggest any further edits. The > document that emerges at the end of this week will be the > input document to Geneva. > > > Kevin > > >

1 0

Re: H.248.1 Editing meeting
by Albrecht.Schwarz＠alcatel.de 28 Jun '05

28 Jun '05

Kevin, thanks for your effort! Can imagine that you can't see the text anymore;-) Nevertheless; I'd like to propose some more editorial change proposals, almost all originating from types or space characters. Unfortunately I'm unable to upload my comments on the avc site: http://ftp3.itu.int/av-arch/avc-site/Incoming/ "You don't have permission to access /av-arch/avc-site/Incoming/ on this server." That's why I'll send the file TD9 Updated Draft_h248.1v3 Clean_commentsALCATEL.doc in a separate email to Kevin directly. Regards Albrecht "Kevin Boyle" <kboyle(a)nortel.c To: itu-sg16(a)external.cisco.com om> cc: Subject: H.248.1 Editing meeting 27.06.2005 11:36 All, I have uploaded two versions of the working document to the Incoming folder on the FTP site -- one with change marks as TD8R1 and one without as TD9. These reflect all the changes through all 5 weeks thus far. The only change I have not made was the addition of Notify to the profile template. There seems to be a problem with the FTP site, in that it will not list the contents of the folders. Once that problem has been resolved, I will update the document to include it. Please look over the document. I have been over the spec in great detail making the capitalization uniform as best I can. If you see any cases that do not align with the rest of the document, please let me know. Also, have a look across the document for the changes you suggested. In some cases, I took the suggestion for change and altered the wording a little differently than suggested. In some cases there were multiple changes to the same place suggested, and I did the best I could to merge the suggestions. Hopefully I have captured the intent of all. I hope you all find my many hours of work satisfactory. As a reminder, this is the week to suggest any further edits. The document that emerges at the end of this week will be the input document to Geneva. Kevin

1 0

H.248.1 Editing meeting
by Kevin Boyle 27 Jun '05

27 Jun '05

All, I have uploaded two versions of the working document to the Incoming folder on the FTP site -- one with change marks as TD8R1 and one without as TD9. These reflect all the changes through all 5 weeks thus far. The only change I have not made was the addition of Notify to the profile template. There seems to be a problem with the FTP site, in that it will not list the contents of the folders. Once that problem has been resolved, I will update the document to include it. Please look over the document. I have been over the spec in great detail making the capitalization uniform as best I can. If you see any cases that do not align with the rest of the document, please let me know. Also, have a look across the document for the changes you suggested. In some cases, I took the suggestion for change and altered the wording a little differently than suggested. In some cases there were multiple changes to the same place suggested, and I did the best I could to merge the suggestions. Hopefully I have captured the intent of all. I hope you all find my many hours of work satisfactory. As a reminder, this is the week to suggest any further edits. The document that emerges at the end of this week will be the input document to Geneva. Kevin

1 0

RE: [Megaco] The ABNF coding of VALUE doesn't allow to represent ageneric UTF-8 string/char
by Steve Cipolli 24 Jun '05

24 Jun '05

Angelo, Today all ASCII characters except double quotes can be specified by the VALUE production (some of the characters need to be in the quotedstring form). Adding UTF-8 does not change this. The part of UTF-8 that is < 0x80 is exactly ASCII and does not change or need to change the way in which VALUE is encoded. UTF-8 characters above 0x7F are encoded as multiple bytes in which each byte of the character is guaranteed to be > 0x7F. So UTF-8 characters are either < 0x80 and are simply the equivalent of ASCII or they are encoded into multiple bytes in which every byte of the character is > 0x7F. There will never be a circumstance where a byte of a UTF-8 multibyte character collides with _any_ ASCII character. Perhaps the table below will help clarify Scalar Value 1st Byte 2nd Byte 3rd Byte 4th Byte 00000000 0xxxxxxx 0xxxxxxx 00000yyy yyxxxxxx 110yyyyy 10xxxxxx zzzzyyyy yyxxxxxx 1110zzzz 10yyyyyy 10xxxxxx 000uuuuu zzzzyyyy yyxxxxxx 11110uuu 10uuzzzz 10yyyyyy 10xxxxxx Notice that "one byte" UTF-8 characters have their high order bit cleared (0) and that all bytes of all multi-byte UTF-8 encodings have the high-order bit set (1). In other words all multi-byte character's bytes are > 0x7F. So changing the productions to: VALUE = quotedString / 1*(SafeChar / %x80-F7) quotedString = DQUOTE *(SafeChar / %x80-F7 / RestChar / WSP) DQUOTE as Sasha Ruditsky suggests will allow UTF-8 characters to be used in VALUEs. ASCII characters (and UTF-8 equvialents < 0x80) that are in the RestChar set will need to be quoted just as they have always been. UTF-8 characters above 0x7F may or may not be quoted, just as all the ASCII characters in the SafeChar set. --Stephen > -----Original Message----- > From: Contardi Angelo [mailto:Angelo.Contardi@italtel.it] > Sent: Friday, June 24, 2005 12:25 PM > To: Steve Cipolli > Subject: R: [Megaco] The ABNF coding of VALUE doesn't allow > to represent ageneric UTF-8 string/char > > > > > -----Messaggio originale----- > Da: Steve Cipolli [mailto:SCipolli@radvision.com] > Inviato: venerdì 24 giugno 2005 18.01 > A: Contardi Angelo; Megaco IETF - Mail List (E-mail) > Cc: Christian Groves (E-mail) > Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow > to represent ageneric UTF-8 string/char > > > > Two points: > > 1. It is not necessary to quote the UTF-8 characters as you > define in your second solution. VALUE can be extended to > accept characters (quoted and unquoted) in the range 0x80-0xFF. > > The problem is that VALUE don't allow to "carry" ALL ASCII > (0x00-0x7F) too, NEEDED to code UTF-8 characters < 0x80. So > the only "extension" 0x80-0xFF is NOT enough to allow the TX > of ALL UTF-8 with ABNF. The quotation is NEEDED becaue of if > you "scan" an input sequence and allow a VALUE as "any > sequence of ono or more 0x00-0xFF", all "tokens" identified > as VALUEs. The extension of quoted form of VALUE i propose > don't increment the number of the forms of VALUE, just EXEND > the actual Quoted form of VALUE > > 2. Providing a mechanism to allow double quotes (") in a > (double) quotedstring is essentially a separate issue, since > addition of UTF-8 chars does not motivate the need for this > mechanism nor complicate its addition. > > See point 1. > > --Stephen > > > -----Original Message----- > > From: megaco-bounces(a)ietf.org > > [mailto:megaco-bounces@ietf.org] On Behalf Of Contardi Angelo > > Sent: Friday, June 24, 2005 11:34 AM > > To: Megaco IETF - Mail List (E-mail) > > Cc: Christian Groves (E-mail) > > Subject: [Megaco] The ABNF coding of VALUE doesn't allow to > > represent ageneric UTF-8 string/char > > > > > > Hello, > > > > from my previous private discussion with Christian Groves, > > i have deduce this: > > > > The ABNF coding of VALUE doesn't allow to represent a > > generic UTF-8 string or char (RFC 3629) because of: > > > > 1) The FIRST byte of an UTF-8 char may be ANY ASCII char in > > the range 0x00-0x7E > > and, for instance, the ASCII 0x00-0x07 and 0x22 (") are > > not allowed in ANY > > ABNF form of VALUE. > > > > 2) Furthermore, UTF-8 chars "greater than 0x7E", need "ASCII > > chars" (to better > > say, Octets) in the range 0x80-0xFF (not ALL), not allowed > > in ANY ABNF form > > of VALUE. > > > > So, to "correct" this problem, i can suggest two possible solutions: > > > > 1) The simple one, code the UTF-8 string/char in "Octect > > Mode", as described in > > ANNEX B.3. This is a BAD solution from the efficiency > > transmission point of > > view because of it "halve the TX band": to TX one UTF-8 > > char (max 4 Octet) > > i must TX max 2 x 4 = 8 Octet (ASCII chars). > > > > 2) The difficult one, allow the ABNF quoted form of VALUE to > > TX ALL ASCII chars > > 0x01-0xFF (the range 0x80-0xFF are more properly named > > OCTET in RFC2234 ), > > except 0x22 ("), that should be ESCAPED with "\", as > > already done for ABNF > > Local and Remote Descriptor (see SDP). Note that '\0' > > (0x00) is NOT ALLOWED > > in this new quoted string form as in the present one, but > > it's not a problem > > because in UTF-8 the char '\0' (0x00) is same as in ASCII > > (string terminator) > > and is NOT used to code "non ASCII" UTF-8 chars, all > > those chars > 0x7F that > > require more than one ASCII chars to be encoded (from 2 to > > 4 ASCII chars). In > > fact the "extra chars" needed to code an UTF-8 char are > > all above 0x7F. > > > > While the 1st mode doesn't require any modification of > > ABNF syntax (but is it applicable in any case ?), the 2nd one > > require this ABNF modification: > > > > quotedString = DQUOTE *(quotedChar) DQUOTE > > > > ; %x22 (") is allowed just if "escaped" with "\" > > quotedChar = ( %x01-21 / "\" DQUOTE / %x23-FF ) > > > > In a parser implementation, i think, this is not a > > "terrible complication" and can be solved in the same way of > > "octetString" of Local and RemoteDescriptor. It require also > > to implement an ESCAPE "strip(rx)/padding(tx)" mechanism, as > > already required for SDP. > > > > P.S.: I suppose NO ONE need to send the "string terminator" > > '\0' (0x00) in an > > UTF-8 string or char. If my assertion is false, in > > the "solution 2)" the > > %x00 should also be "escaped". Viceversa, the > > "solution 1)" can already > > "transport" %x00 octet. > > > > Best regards > > > > o o o o o o o . . . ___________________________________ > > o _____ || Angelo Contardi | > > .][__n_n_|DD[ ====_____ | angelo.contardi(a)italtel.it | > > >(________|__|_[_________]_|________________________________| > > _/oo OOOOO oo` ooo ooo 'o!o!o o!o!o` > > > > _______________________________________________ > > Megaco mailing list > > Megaco(a)ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > > > >

1 0

RE: [Megaco] The ABNF coding of VALUE doesn't allow to representageneric UTF-8 string/char
by Steve Cipolli 24 Jun '05

24 Jun '05

Angelo, Today all ASCII characters except double quotes can be specified by the VALUE production (some of the characters need to be in the quotedstring form). Adding UTF-8 does not change this. The part of UTF-8 that is < 0x80 is exactly ASCII and does not change or need to change the way in which VALUE is encoded. UTF-8 characters above 0x7F are encoded as multiple bytes in which each byte of the character is guaranteed to be > 0x7F. So UTF-8 characters are either < 0x80 and are simply the equivalent of ASCII or they are encoded into multiple bytes in which every byte of the character is > 0x7F. There will never be a circumstance where a byte of a UTF-8 multibyte character collides with _any_ ASCII character. Perhaps the table below will help clarify Scalar Value 1st Byte 2nd Byte 3rd Byte 4th Byte 00000000 0xxxxxxx 0xxxxxxx 00000yyy yyxxxxxx 110yyyyy 10xxxxxx zzzzyyyy yyxxxxxx 1110zzzz 10yyyyyy 10xxxxxx 000uuuuu zzzzyyyy yyxxxxxx 11110uuu 10uuzzzz 10yyyyyy 10xxxxxx Notice that "one byte" UTF-8 characters have their high order bit cleared (0) and that all bytes of all multi-byte UTF-8 encodings have the high-order bit set (1). In other words all multi-byte character's bytes are > 0x7F. So changing the productions to: VALUE = quotedString / 1*(SafeChar / %x80-F7) quotedString = DQUOTE *(SafeChar / %x80-F7 / RestChar / WSP) DQUOTE as Sasha Ruditsky suggests will allow UTF-8 characters to be used in VALUEs. ASCII characters (and UTF-8 equvialents < 0x80) that are in the RestChar set will need to be quoted just as they have always been. UTF-8 characters above 0x7F may or may not be quoted, just as all the ASCII characters in the SafeChar set. --Stephen > -----Original Message----- > From: Contardi Angelo [mailto:Angelo.Contardi@italtel.it] > Sent: Friday, June 24, 2005 12:25 PM > To: Steve Cipolli > Subject: R: [Megaco] The ABNF coding of VALUE doesn't allow > to represent ageneric UTF-8 string/char > > > > > -----Messaggio originale----- > Da: Steve Cipolli [mailto:SCipolli@radvision.com] > Inviato: venerdì 24 giugno 2005 18.01 > A: Contardi Angelo; Megaco IETF - Mail List (E-mail) > Cc: Christian Groves (E-mail) > Oggetto: RE: [Megaco] The ABNF coding of VALUE doesn't allow > to represent ageneric UTF-8 string/char > > > > Two points: > > 1. It is not necessary to quote the UTF-8 characters as you > define in your second solution. VALUE can be extended to > accept characters (quoted and unquoted) in the range 0x80-0xFF. > > The problem is that VALUE don't allow to "carry" ALL ASCII > (0x00-0x7F) too, NEEDED to code UTF-8 characters < 0x80. So > the only "extension" 0x80-0xFF is NOT enough to allow the TX > of ALL UTF-8 with ABNF. The quotation is NEEDED becaue of if > you "scan" an input sequence and allow a VALUE as "any > sequence of ono or more 0x00-0xFF", all "tokens" identified > as VALUEs. The extension of quoted form of VALUE i propose > don't increment the number of the forms of VALUE, just EXEND > the actual Quoted form of VALUE > > 2. Providing a mechanism to allow double quotes (") in a > (double) quotedstring is essentially a separate issue, since > addition of UTF-8 chars does not motivate the need for this > mechanism nor complicate its addition. > > See point 1. > > --Stephen > > > -----Original Message----- > > From: megaco-bounces(a)ietf.org > > [mailto:megaco-bounces@ietf.org] On Behalf Of Contardi Angelo > > Sent: Friday, June 24, 2005 11:34 AM > > To: Megaco IETF - Mail List (E-mail) > > Cc: Christian Groves (E-mail) > > Subject: [Megaco] The ABNF coding of VALUE doesn't allow to > > represent ageneric UTF-8 string/char > > > > > > Hello, > > > > from my previous private discussion with Christian Groves, > > i have deduce this: > > > > The ABNF coding of VALUE doesn't allow to represent a > > generic UTF-8 string or char (RFC 3629) because of: > > > > 1) The FIRST byte of an UTF-8 char may be ANY ASCII char in > > the range 0x00-0x7E > > and, for instance, the ASCII 0x00-0x07 and 0x22 (") are > > not allowed in ANY > > ABNF form of VALUE. > > > > 2) Furthermore, UTF-8 chars "greater than 0x7E", need "ASCII > > chars" (to better > > say, Octets) in the range 0x80-0xFF (not ALL), not allowed > > in ANY ABNF form > > of VALUE. > > > > So, to "correct" this problem, i can suggest two possible solutions: > > > > 1) The simple one, code the UTF-8 string/char in "Octect > > Mode", as described in > > ANNEX B.3. This is a BAD solution from the efficiency > > transmission point of > > view because of it "halve the TX band": to TX one UTF-8 > > char (max 4 Octet) > > i must TX max 2 x 4 = 8 Octet (ASCII chars). > > > > 2) The difficult one, allow the ABNF quoted form of VALUE to > > TX ALL ASCII chars > > 0x01-0xFF (the range 0x80-0xFF are more properly named > > OCTET in RFC2234 ), > > except 0x22 ("), that should be ESCAPED with "\", as > > already done for ABNF > > Local and Remote Descriptor (see SDP). Note that '\0' > > (0x00) is NOT ALLOWED > > in this new quoted string form as in the present one, but > > it's not a problem > > because in UTF-8 the char '\0' (0x00) is same as in ASCII > > (string terminator) > > and is NOT used to code "non ASCII" UTF-8 chars, all > > those chars > 0x7F that > > require more than one ASCII chars to be encoded (from 2 to > > 4 ASCII chars). In > > fact the "extra chars" needed to code an UTF-8 char are > > all above 0x7F. > > > > While the 1st mode doesn't require any modification of > > ABNF syntax (but is it applicable in any case ?), the 2nd one > > require this ABNF modification: > > > > quotedString = DQUOTE *(quotedChar) DQUOTE > > > > ; %x22 (") is allowed just if "escaped" with "\" > > quotedChar = ( %x01-21 / "\" DQUOTE / %x23-FF ) > > > > In a parser implementation, i think, this is not a > > "terrible complication" and can be solved in the same way of > > "octetString" of Local and RemoteDescriptor. It require also > > to implement an ESCAPE "strip(rx)/padding(tx)" mechanism, as > > already required for SDP. > > > > P.S.: I suppose NO ONE need to send the "string terminator" > > '\0' (0x00) in an > > UTF-8 string or char. If my assertion is false, in > > the "solution 2)" the > > %x00 should also be "escaped". Viceversa, the > > "solution 1)" can already > > "transport" %x00 octet. > > > > Best regards > > > > o o o o o o o . . . ___________________________________ > > o _____ || Angelo Contardi | > > .][__n_n_|DD[ ====_____ | angelo.contardi(a)italtel.it | > > >(________|__|_[_________]_|________________________________| > > _/oo OOOOO oo` ooo ooo 'o!o!o o!o!o` > > > > _______________________________________________ > > Megaco mailing list > > Megaco(a)ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > > > > _______________________________________________ Megaco mailing list Megaco(a)ietf.org https://www1.ietf.org/mailman/listinfo/megaco

1 0

RE: H.248 and UTF-8 strings.
by Sasha Ruditsky 24 Jun '05

24 Jun '05

Hi Tom I am reading RFC2234 and in 2.4 it says: "External representations of terminal value characters will vary according to constraints in the storage or transmission environment. Hence, the same ABNF-based grammar may have multiple external encodings, such as one for a 7-bit US-ASCII environment, another for a binary octet environment and still a different one when 16-bit Unicode is used. Encoding details are beyond the scope of ABNF, although Appendix A (Core) provides definitions for a 7-bit US-ASCII environment as has been common to much of the Internet." So me from here I conclude that encoding is not defined by RFC2234. Now in Appendix A, a.k.a section 6 one can find: In 6.1 it shows OCTET = %x00-FF However section 6.2 says that that only 7 bit values are allowed. Taking this into account and the fact that Appendix A of RFC 2234 represents informative (not normative) part of the document, I do not see how and why it should be followed. You are saying, that "We adopted that core for Megaco". I've failed to find any reference in the Megaco documents to RFC2234 Appendix A or section 6.2. And as I wrote before, Megaco document does have the following definition: nonEscapeChar = ( "\}" / %x01-7C / %x7E-FF ) which definitely requires encoding which supports 8 bit values. And Megaco document claims support for UTF-8 string which also need 8 bit values support. Regards, Sasha -----Original Message----- From: Tom Taylor [mailto:taylor@nortel.com] Sent: Friday, June 24, 2005 11:07 AM To: Sasha Ruditsky Cc: Christian Groves; itu-sg16(a)external.cisco.com; Angelo.Contardi(a)ITALTEL.IT Subject: Re: H.248 and UTF-8 strings. Appendix A in which section 6.2 appears is "a convenient core for specific grammars". We adopted that core for Megaco. In fact, ABNF can be more general. When I look at the first paragraph of section 2.3 I see: "Rules resolve into a string of terminal values, sometimes called characters. In ABNF a character is merely a non-negative integer. In certain contexts a specific mapping (encoding) of values into a character set (such as ASCII) will be specified." Note further down, however, that: "Literal text strings" [i.e. strings between quotes] "are interpreted as a concatenated set of printable characters." and printable characters are defined in Appendix A to be VCHAR = %x21-7E ; visible (printing) characters BTW I seem to be unsubscribed from the SG 16 (Cisco) list and therefore no longer authorized to post to it. The list is therefore not seeing my responses. Sasha Ruditsky wrote: > Hi Tom > > Then I am flummoxed by the line: > OCTET = %x00-FF > Which appears several lines before the 6.2 in the same RFC2234. > > In addition Megaco already has the following definition: > nonEscapeChar = ( "\}" / %x01-7C / %x7E-FF ) > > How then these are encoded? > > Regards, > Sasha > > > -----Original Message----- > From: Tom Taylor [mailto:taylor@nortel.com] > Sent: Friday, June 24, 2005 9:30 AM > To: Christian Groves > Cc: Sasha Ruditsky; itu-sg16(a)external.cisco.com; > Angelo.Contardi(a)ITALTEL.IT > Subject: Re: H.248 and UTF-8 strings. > > I'd guess the restriction came from RFC 2234 (ABNF). See paragraph 6.2. > > Christian Groves wrote: > >>Hello Sasha, >> >>You're quite welcome to bring in a contribution to the July Meeting on > > >>this issue (addressed to Q.3- same procedure as any question), >>although I hope that there will be some agreement on the solution on >>the Megaco list. Those that can remember that far back know that I >>wasn't really a proponent of the text encoding so I can't remember why > > >>these "extra chars" were excluded in the first place. I've added Tom >>to see if he can remember. In terms of solution I would support adding > > >>this to VALUE only as indicated below. >> >>Regards, Christian >> >>Sasha Ruditsky wrote: >> >> >>>Hi Christian >>> >>>As you correctly stated all the "extra chars" are the region between >>>0x80 and 0xff (0xf7 to be precise). >>>I am not aware about any special meaning of the characters from this >>>region, so as a result I cannot understand why these "extra chars" >>>need to be escaped or quoted in any way. >>> >>>The naive question is what is wrong with extending SafeChar to >>>contain this region? >>>I.e. >>> SafeChar = DIGIT / ALPHA / "+" / "-" / "&" / >>> "!" / "_" / "/" / "\'" / "?" / "@" / >>> "^" / "`" / "~" / "*" / "$" / "\" / >>> "(" / ")" / "%" / "|" / "." / %x80-F7 Or, >>>if for some reason the UTF-8 strings may be used only in VALUE, >>>then: >>> >>> VALUE = quotedString / 1*(SafeChar / %x80-F7) >>> quotedString = DQUOTE *(SafeChar / %x80-F7 / RestChar / > > WSP) > >>>DQUOTE >>> >>> >>> >>>And... >>> >>>Assuming that the way to fix this is found, can it be fixed in ver 3? >>>If yes, then what is the procedure? >>>Do you want me to bring relevant contribution to July meeting? >>> >>>Thanks, >>>Sasha >>> >>> >>> >>> >>> >>>-----Original Message----- >>>From: Christian Groves [mailto:christian.groves@ericsson.com] Sent: >>>Wednesday, June 22, 2005 8:16 PM >>>To: Sasha Ruditsky >>>Cc: itu-sg16(a)external.cisco.com; Angelo.Contardi(a)italtel.it >>>Subject: Re: H.248 and UTF-8 strings. >>> >>>Hello Sasha, >>> >>>This problem was raised recently on the Megaco list. I've had some >>>off-line discussion with Angelo (the person who raised the problem) >>>and currently there's >>>2 proposed solutions (I hope he would sent this to the Megaco list): >>> >>>1) The simple one, Code the UTF-8 string in "Octect Mode". This is a >>>BAD solution from the efficiency transmission point of view because >>>of it "halve the TX band": to TX one UTF-8 char (max 4 ASCII chars) i > > >>>must TX max 2 x 4 = 8 ASCII chars. >>> >>>2) The complicated one, allow the ABNF quoted form of VALUE to TX ALL > > >>>ASCII chars 0x01-0xFF, except 0x22, that should be ESCAPED with "\", >>>as already done for ABNF Local and Remote Descriptor (see SDP). Note >>>that '\0' (0x00) is NOT ALLOWED in this new quoted string form as in >>>the present one, but this is not a problem because in UTF-8 the char > > '\0' > >>>(0x00) is the same as in ASCII (string terminator) and is NOT used to > > >>>code "non ASCII" UTF-8 chars, all those chars > 0x7F that require >>>more than one ASCII chars to be encoded (from 2 to 4 ASCII chars). In > > >>>fact the "extra chars" needed to code an UTF-8 char are all above >>>0x7F (have the MSBit = 1). >>> >>>Regards, Christian >>> >>>Sasha Ruditsky wrote: >>> >>> >>> >>>>Hi >>>> >>>>I'm trying to understand how H.248 supports UTF-8 string properties. >>>>According to H.248 the string property is encoded as UTF-8 string. >>>> >>>>UTF-8 encoding is defined by the following table: >>>> >>>>Scalar Value 1st Byte 2nd Byte 3rd Byte 4th Byte >>>>00000000 0xxxxxxx 0xxxxxxx >>>>00000yyy yyxxxxxx 110yyyyy 10xxxxxx >>>>zzzzyyyy yyxxxxxx 1110zzzz 10yyyyyy 10xxxxxx >>>>000uuuuu zzzzyyyy yyxxxxxx 11110uuu 10uuzzzz 10yyyyyy 10xxxxxx >>>> >>>> >>>>I.e. all the character codes between x80 and xf7 need to be > > supported. > >>>>According to H.248 Annex B.2: >>>> >>>>The ABNF in this section uses the VALUE construct (or lists of VALUE >>>>constructs) to encode various package element values (properties, >>>>signal parameters, etc.). >>>> >>>>The VALUE is defined as follows: >>>> >>>> VALUE = quotedString / 1*(SafeChar) >>>> SafeChar = DIGIT / ALPHA / "+" / "-" / "&" / >>>> "!" / "_" / "/" / "\'" / "?" / "@" / >>>> "^" / "`" / "~" / "*" / "$" / "\" / >>>> "(" / ")" / "%" / "|" / "." >>>> ALPHA = %x41-5A / %x61-7A ; A-Z / a-z >>>> DIGIT = %x30-39 ; 0-9 >>>> quotedString = DQUOTE *(SafeChar / RestChar/ WSP) DQUOTE >>>> RestChar = ";" / "[" / "]" / "{" / "}" / ":" / "," / > > "#" > >>> >>>/ >>> >>> >>>> "<" / ">" / "=" >>>> WSP = SP / HTAB ; white space >>>> SP = %x20 ; space >>>> HTAB = %x09 ; horizontal tab >>>> DQUOTE = %x22 ; " (Double Quote) >>>> >>>> >>>>So I believe this excludes the x80-xff characters. >>>> >>>>So the question is how to text encoding defined in Annex B to encode >>>>UTF-8 strings? >>>> >>>>Thanks, >>>>Sasha >>>> >>> >>> >> > > > >

1 0