- sg16-avd - lists.packetizer.com

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

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

24 Jun '05

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

FW: I-D ACTION:draft-cheshire-nat-pmp-00.txt
by Euchner Martin 24 Jun '05

24 Jun '05

Just for your information to Q.5/16 NAT experts. I'm really not certain if this new NAT protocol has any value for our MM NAT problems in SG16? 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@ties.itu.int | Hofmannstr. 51 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: i-d-announce-bounces(a)ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts(a)ietf.org Sent: Donnerstag, 23. Juni 2005 21:50 To: i-d-announce(a)ietf.org Subject: I-D ACTION:draft-cheshire-nat-pmp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAT Port Mapping Protocol (NAT-PMP) Author(s) : S. Cheshire, et al. Filename : draft-cheshire-nat-pmp-00.txt Pages : 15 Date : 2005-6-23 This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the public IP address of a NAT gateway, thus allowing a client to make this public IP address and port number known to peers that may wish to communicate with it. This protocol is implemented in current Apple products including Mac OS X v10.4 Tiger and Bonjour for Windows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cheshire-nat-pmp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request(a)ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-cheshire-nat-pmp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-cheshire-nat-pmp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------------------------------------------------------------------------- CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY ------------------------------------------------------------------------- In order to maintain computing infrastructure integrity, Cisco Systems Enterprise Messaging Services and InfoSec teams have set a mail policy disallowing executable attachments in email. This message contained an executable attachment type that is prohibited by this policy. The attachment has been removed from this message and copied to quarantine by our systems. It will be held in quarantine for seven days in the event that the content needs to be retrieved. Please be aware many viruses attempt to look like legitimate email or notifications from anti-virus systems. We will clearly mark a seperation between our notifications and the original email as follows: "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" For further reference information about viruses and email antivirus efforts within Cisco, please visit: http://wwwin.cisco.com/it/ems/services/antiviral If your concern isn't addressed by the information in this notification or the above web page, you may open a support request: http://wwwin.cisco.com/support/ Select "Messaging", "Email-Related", "Mail Routing" Please include in the text of your case the following information: * Full headers of the message. Documentation on displaying the full headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html * This unique quarantine identifier: j5O8ND94022256 If the matter is urgent, you may follow up by calling one of the below referenced numbers. Please make every effort to provide the above requested information via the support web tool prior to calling as it will greatly aid the resolution of your issue. Americas: 1 408 526 8888 Asiapac +61 2 8446 8888 EMEA +31 20 485 4888 Japan +81 3 5549 6888 US (Toll Free) 1| 800| 888| 8187| (ext.68888) Thank you for your cooperation, Enterprise Messaging Services Cisco Systems, Inc

1 0

Re: H.248 and UTF-8 strings.
by Christian Groves 23 Jun '05

23 Jun '05

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

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

23 Jun '05

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

Re: H.248 and UTF-8 strings.
by Christian Groves 22 Jun '05

22 Jun '05

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

H.248 and UTF-8 strings.
by Sasha Ruditsky 22 Jun '05

22 Jun '05

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

Final Comments for Week 5
by Picha, Marianne (Marianne) 22 Jun '05

22 Jun '05

Kevin, Attached are a few more editorial comments. Sorry for the Delay. Regards, Marianne Picha

1 0

unsubscribe
by Kamalakanta Palei 22 Jun '05

22 Jun '05

_____ Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football <http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=33539/*http://football.fa ntasysports.yahoo.com?ovchn=YAH&ovcpn=Integration&ovcrn=Mail+footer&ovrfd= YAH&ovtac=AD>

1 0

Re: unsubscribe
by Kamalakanta Palei 22 Jun '05

22 Jun '05

Vehbi Sheholli <Vehbi.Sheholli(a)PTKONLINE.COM> wrote: -----Original Message----- From: FCG Wang JuLin [mailto:JuLin.Wang@alcatel-sbell.com.cn] Sent: Wednesday, June 22, 2005 3:04 AM To: itu-sg16(a)external.cisco.com Subject: unsubscribe __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: unsubscribe
by Kamalakanta Palei 22 Jun '05

22 Jun '05

Vehbi Sheholli <Vehbi.Sheholli(a)PTKONLINE.COM> wrote: -----Original Message----- From: FCG Wang JuLin [mailto:JuLin.Wang@alcatel-sbell.com.cn] Sent: Wednesday, June 22, 2005 3:04 AM To: itu-sg16(a)external.cisco.com Subject: unsubscribe __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

unsubscribe
by Vehbi Sheholli 22 Jun '05

22 Jun '05

-----Original Message----- From: FCG Wang JuLin [mailto:JuLin.Wang@alcatel-sbell.com.cn] Sent: Wednesday, June 22, 2005 3:04 AM To: itu-sg16(a)external.cisco.com Subject: unsubscribe

1 0

Re: 8. H.248.1: Value of Statistics at a Termination Level; Re: H.248 .1
by Albrecht.Schwarz＠alcatel.de 22 Jun '05

22 Jun '05

Proposal is OK from my side. Regards/Albrecht Christian Groves <christian.groves@er To: Albrecht SCHWARZ/DE/ALCATEL@ALCATEL icsson.com> cc: SG16 <itu-sg16(a)external.cisco.com>, Kevin Boyle <kboyle(a)nortel.com> Subject: Re: 8. H.248.1: Value of Statistics at a Termination Level; Re: 22.06.2005 09:19 H.248 .1 Editing Meeting Week 4 comments Hello Albrecht, You have a good point about that the "superior function" could be something other than the "sum" it could in fact be the "average" and mostly dependent on statistic type. I think your proposal still leaves it open what to do with a termination level statistic. I would like to see at least a default behaviour like "sum", I also think that we should say that this may be modified by an individual statistic definition. That way if someone doesn't add text (eg. all the existing statistics) then a certain behaviour can be assumed. Would the following text be agreeable: "The value of a Statistic at a Termination level is the result of a meaningful superior function (like for instance sum or average)of the values as if it had been placed on all the streams in the termination. Such a superior function is dependent of the particular statistic type. Unless specified otherwise in the package that defines a particular statistic, the default behaviour is a sum of the values." Regards, Christian Albrecht.Schwarz(a)alcatel.de wrote: > Hi Christian et al., > > I concur with Christian's proposals. > I know I'm behind week 4, but when looking at the nt statistics, I'm > again > not sure whether the additions for item 8 are sufficient. > > Current proposal: > "The value of a Statistic at a Termination level is the sum of the > values > as if it had been placed on all the streams in the termination." > > Discussion: > The statistic on Termination level is superior concerning the Stream > level > statistics. > Thus, there needs to be a "superior function" for the Termination > statistic. Crucial: such a function is "statistic type" dependent. > "sum" is an example for a "superior function", "average" another one > (e.g., > applicable for some time-based statistics like "delay" or "delay > variation"). > > Generally there are two possibilities here: > (1) Statistic was initially defined for "Streams", afterwards a > meaningful > "superior statistic" for "Terminations" is demanded. > > or > (2) Statistic was initially defined for "Terminations", afterwards an > adaption for "Streams" is demanded. > > The 2nd case seems to be straighforward, the first case is our issue > here. > > New proposal: > "The value of a Statistic at a Termination level is the result of a > meaningful superior function (like for instance sum or average)of the > values as if it had been placed on all the streams in the termination. > Such a superior function is dependent of the particular statistic type." > > Comments? > Regards > > Albrecht > > > > > > Christian Groves > > <christian.groves@ER To: SG16 > <itu-sg16(a)external.cisco.com> > ICSSON.COM> cc: Kevin Boyle > <kboyle(a)nortel.com> > Subject: [SUSPECT > ATTACHMENT] H.248.1 Editing Meeting Week 4 comments > 17.06.2005 06:05 > > > > > > > > Hello Kevin, all, > > Please find attached my comments for week 4 of the editing meeting. > Rather > than > a marked up document its in the form of an IG update. I have attempted > to > capture items that have been discussed on the Megaco list or have been > mentioned > in Tispan. I'm not sure whether all the items fall into the realm of > editorial > only but none of the items add new functionality. I intend on presenting > this DC > (with any new raised issues) to the July meeting. > > Of interest to the Week 4 ABNF are items 1,2 and 3. > > Comments? > > Regards, Christian > ------------------------------------------------------------------------ > - > CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY > ------------------------------------------------------------------------ > - > WARNING: This message has an attachment that could contain executable > code. > > Please review the attachment carefully to ensure you do not > inadvertently > execute embedded programs that could contain viruses. > > We suggest you review the following URL to stay up-to-date with current > virus threats: > > http://wwwin.cisco.com/support/library/mcafee/virus_info.shtml > > Please be aware many viruses attempt to look like legitimate email or > notifications from anti-virus systems. We will clearly mark a seperation > between our notifications and the original email as follows: > > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" > > For further reference information about viruses and email antivirus > efforts within Cisco, please visit: > > http://wwwin.cisco.com/it/ems/services/antiviral > > If your concern isn't addressed by the information in this notification > or the above web page, you may open a support request: > > http://wwwin.cisco.com/support/ > > Select "Messaging", "Email-Related", "Mail Routing" > > Please include in the text of your case the following information: > > * Full headers of the message. Documentation on displaying the full > headers is available at this URL: > > http://wwwin.cisco.com/support/library/faqs/solution002471.html > > * This unique quarantine identifier: j5H45lQ3023840 > > If the matter is urgent, you may follow up by calling one of the below > referenced numbers. Please make every effort to provide the above > requested information via the support web tool prior to calling as it > will greatly aid the resolution of your issue. > > Americas: > 1 408 526 8888 > > Asiapac > +61 2 8446 8888 > > EMEA > +31 20 485 4888 > > Japan > +81 3 5549 6888 > > US (Toll Free) > 1| 800| 888| 8187| (ext.68888) > > Thank you for your cooperation, > > Enterprise Messaging Services > Cisco Systems, Inc > (See attached file: DC-xxx_H_248_1v3_Corrections_Clarifications.zip) > >

1 0

Re: 8. H.248.1: Value of Statistics at a Termination Level; Re: H.248
by Christian Groves 22 Jun '05

22 Jun '05

Hello Albrecht, You have a good point about that the "superior function" could be something other than the "sum" it could in fact be the "average" and mostly dependent on statistic type. I think your proposal still leaves it open what to do with a termination level statistic. I would like to see at least a default behaviour like "sum", I also think that we should say that this may be modified by an individual statistic definition. That way if someone doesn't add text (eg. all the existing statistics) then a certain behaviour can be assumed. Would the following text be agreeable: "The value of a Statistic at a Termination level is the result of a meaningful superior function (like for instance sum or average)of the values as if it had been placed on all the streams in the termination. Such a superior function is dependent of the particular statistic type. Unless specified otherwise in the package that defines a particular statistic, the default behaviour is a sum of the values." Regards, Christian Albrecht.Schwarz(a)alcatel.de wrote: > Hi Christian et al., > > I concur with Christian's proposals. > I know I'm behind week 4, but when looking at the nt statistics, I'm > again > not sure whether the additions for item 8 are sufficient. > > Current proposal: > "The value of a Statistic at a Termination level is the sum of the > values > as if it had been placed on all the streams in the termination." > > Discussion: > The statistic on Termination level is superior concerning the Stream > level > statistics. > Thus, there needs to be a "superior function" for the Termination > statistic. Crucial: such a function is "statistic type" dependent. > "sum" is an example for a "superior function", "average" another one > (e.g., > applicable for some time-based statistics like "delay" or "delay > variation"). > > Generally there are two possibilities here: > (1) Statistic was initially defined for "Streams", afterwards a > meaningful > "superior statistic" for "Terminations" is demanded. > > or > (2) Statistic was initially defined for "Terminations", afterwards an > adaption for "Streams" is demanded. > > The 2nd case seems to be straighforward, the first case is our issue > here. > > New proposal: > "The value of a Statistic at a Termination level is the result of a > meaningful superior function (like for instance sum or average)of the > values as if it had been placed on all the streams in the termination. > Such a superior function is dependent of the particular statistic type." > > Comments? > Regards > > Albrecht > > > > > > Christian Groves > > <christian.groves@ER To: SG16 > <itu-sg16(a)external.cisco.com> > ICSSON.COM> cc: Kevin Boyle > <kboyle(a)nortel.com> > Subject: [SUSPECT > ATTACHMENT] H.248.1 Editing Meeting Week 4 comments > 17.06.2005 06:05 > > > > > > > > Hello Kevin, all, > > Please find attached my comments for week 4 of the editing meeting. > Rather > than > a marked up document its in the form of an IG update. I have attempted > to > capture items that have been discussed on the Megaco list or have been > mentioned > in Tispan. I'm not sure whether all the items fall into the realm of > editorial > only but none of the items add new functionality. I intend on presenting > this DC > (with any new raised issues) to the July meeting. > > Of interest to the Week 4 ABNF are items 1,2 and 3. > > Comments? > > Regards, Christian > ------------------------------------------------------------------------ > - > CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY > ------------------------------------------------------------------------ > - > WARNING: This message has an attachment that could contain executable > code. > > Please review the attachment carefully to ensure you do not > inadvertently > execute embedded programs that could contain viruses. > > We suggest you review the following URL to stay up-to-date with current > virus threats: > > http://wwwin.cisco.com/support/library/mcafee/virus_info.shtml > > Please be aware many viruses attempt to look like legitimate email or > notifications from anti-virus systems. We will clearly mark a seperation > between our notifications and the original email as follows: > > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" > > For further reference information about viruses and email antivirus > efforts within Cisco, please visit: > > http://wwwin.cisco.com/it/ems/services/antiviral > > If your concern isn't addressed by the information in this notification > or the above web page, you may open a support request: > > http://wwwin.cisco.com/support/ > > Select "Messaging", "Email-Related", "Mail Routing" > > Please include in the text of your case the following information: > > * Full headers of the message. Documentation on displaying the full > headers is available at this URL: > > http://wwwin.cisco.com/support/library/faqs/solution002471.html > > * This unique quarantine identifier: j5H45lQ3023840 > > If the matter is urgent, you may follow up by calling one of the below > referenced numbers. Please make every effort to provide the above > requested information via the support web tool prior to calling as it > will greatly aid the resolution of your issue. > > Americas: > 1 408 526 8888 > > Asiapac > +61 2 8446 8888 > > EMEA > +31 20 485 4888 > > Japan > +81 3 5549 6888 > > US (Toll Free) > 1| 800| 888| 8187| (ext.68888) > > Thank you for your cooperation, > > Enterprise Messaging Services > Cisco Systems, Inc > (See attached file: DC-xxx_H_248_1v3_Corrections_Clarifications.zip) > >

1 0

Re: The question about extension of an H.248 package.
by Christian Groves 22 Jun '05

22 Jun '05

Hello Sasha, It looks like the editorial version was fixed by the TSB during publishing. The published version uses cvsp. Regards, Christian Sasha Ruditsky wrote: > Hi Christian > > Thanks, > I understand now the definition of vwp/wxp and vwp/wyp. > > Regarding to the editorial problem. > In the version, which I have (which is TD33(PLEN) from Geneva Jan 2004 > meeting) in the figure 8 the text says: > > Property Group 1 > vwp/vid=1,vwp/wseq=1,vwp/wxp=2500,vwp/wyp=0, > vwp/wh=7500,vwp/wl=5000,vwpcvsp/ovs=2 > Property Group 2 > vwp/vid=2,vwp/wseq=2,vwp/wxp=5000,vwp/wyp=2500, > vwp/wh=7500,vwp/wl=5000,vwpcvsp/ovs=1 > > > Regards, > Sasha > > -----Original Message----- > From: Christian Groves [mailto:christian.groves@ERICSSON.COM] > Sent: Sunday, June 19, 2005 10:21 PM > To: Sasha Ruditsky > Cc: itu-sg16(a)external.cisco.com > Subject: Re: The question about extension of an H.248 package. > > Hello Sasha, > > Please see my response below. > > Regards, Christian > > Sasha Ruditsky wrote: > > >>Hi Christian >> >>Thanks, again. >> >>It looks like I will have some more question about H.248.19. >> >>Meanwhile. >> >>In H.248.19 defines vwp/wxp and vwp/wyp as being from 0 to 10000. >> >>The description text states: >>This property is set by the MC to represent the horizontal "X" >>position of the bottom left hand corner of a window. >>0 represents the left hand side of a screen, 10000 the right hand side > > >>of a screen. >> >>So it makes the size of the screen equal to 10001 units. >> >>In the same time vwp/wh and vwp/wl are also defined to be 0 to 10000. >> >>I think it means that it is impossible to create window which fills >>the entire screen. >>(Screen is 10001 units and the biggest window is only 10000). > > > [CHG] Given a display 10000 by 10000 pixels the way I saw the property > working was that 0,0 represented the bottom left hand corner of the > display/window. A window position 0,0 size 1,1 would draw a pixel 1,1 > starting at this point. A window placed at 10000,10000 couldn't actually > have a positive size as it would exceed the display. > > >>Do I misunderstand the description text? >>Shouldn't the vwp/wxp and vwp/wyp be defined in range from 0 to 9999? >>Or probably the range is OK, however the 10000 is outside of screen? > > > [CHG] So technically 10000 is outside the meaningful range for > displaying anything. > > >>What do you think? >>==================================================================== >> >>Another small editorial issue is that in H.248.19 on Figure 8 the text > > >>references the vwpcvsp/ovs, where I believe it should be cvsp/ovs. > > > [CHG] Is the editorial issue in Figure 8 itself? It should be cvsp/ovs > but I can't see where the error occurs. > > >> >> >>Thanks, >>Sasha >> >> >> >> >>-----Original Message----- >>From: Christian Groves [mailto:christian.groves@ericsson.com] >>Sent: Thursday, June 16, 2005 8:55 PM >>To: Sasha Ruditsky >>Cc: itu-sg16(a)external.cisco.com >>Subject: Re: The question about extension of an H.248 package. >> >>Hello Sasha, >> >>In thus case the text encoding would use H.248.15 Gateway control >>protocol: SDP >>H.248 package attribute. >> >>Regards, Christian >> >>Sasha Ruditsky wrote: >> >> >> >>>Hi Christian >>> >>>Thanks. >>> >>>One more question. >>>In H.248.19 most of the properties inside packages are specified to be >> >> >>>"Defined in: Local/Remote". >>>>From what I know about H.248 -- local/remote descriptors contain SDP >>>messages. >>> >>>How do the H.248.19 properties coexist with SDP? >>>Is it only possible in binary encoding mode? >>> >>>Thanks, >>>Sasha >>> >>>-----Original Message----- >>>From: Christian Groves [mailto:christian.groves@ERICSSON.COM] >>>Sent: Thursday, June 16, 2005 12:35 AM >>>To: Sasha Ruditsky >>>Cc: itu-sg16(a)external.cisco.com >>>Subject: Re: The question about extension of an H.248 package. >>> >>>Hello Sasha, >>> >>>There is no hard rule of what to propose. It really depends on the >>>type of information you want added. >>> >>>I think the only time the package extension should be used is if the >>>added properties/signals/events provide a set of functions of their >>>own right. e.g. >>>would it makes sense that these properties could be a package by >>>themselves but need another package to operate. For example: The tone >>>gen package. The DTMF was added as a extension package as DTMF >>>generation is its own subset functionality but is related to the >>>generation of tones. >>> >>>Regards, Christian >>> >>>Sasha Ruditsky wrote: >>> >>> >>> >>> >>>>Hi >>>> >>>>I'm working on a proposal for July meeting to add some new properties > > >>>>to one of the H.248.19 packages. >>>>>From H.248 document it appears that there are defined (at least) two >>>>ways of doing this. >>>> >>>>* Creating a new version of an existing package >>>>* Creating a new package that extends the existing one. >>>> >>>> >>>>Can somebody please comment on the factors helping to determine which > > >>>>of these two mechanisms should be uses? >>>> >>>>Thanks, >>>>Sasha >>>>. >>>> >>> >>> >> >

1 0

unsubscribe
by FCG Wang JuLin 21 Jun '05

21 Jun '05

1 0

H.248.1 V3 Week 5 Comments
by Picha, Marianne (Marianne) 21 Jun '05

21 Jun '05

Attached are my comments - through section F.4.1.1 Marianne <<TD7 Week 5 Comments mpicha.doc>>

1 0

RE: The question about extension of an H.248 package.
by Sasha Ruditsky 21 Jun '05

21 Jun '05

Hi Christian Thanks, I understand now the definition of vwp/wxp and vwp/wyp. Regarding to the editorial problem. In the version, which I have (which is TD33(PLEN) from Geneva Jan 2004 meeting) in the figure 8 the text says: Property Group 1 vwp/vid=1,vwp/wseq=1,vwp/wxp=2500,vwp/wyp=0, vwp/wh=7500,vwp/wl=5000,vwpcvsp/ovs=2 Property Group 2 vwp/vid=2,vwp/wseq=2,vwp/wxp=5000,vwp/wyp=2500, vwp/wh=7500,vwp/wl=5000,vwpcvsp/ovs=1 Regards, Sasha -----Original Message----- From: Christian Groves [mailto:christian.groves@ERICSSON.COM] Sent: Sunday, June 19, 2005 10:21 PM To: Sasha Ruditsky Cc: itu-sg16(a)external.cisco.com Subject: Re: The question about extension of an H.248 package. Hello Sasha, Please see my response below. Regards, Christian Sasha Ruditsky wrote: > Hi Christian > > Thanks, again. > > It looks like I will have some more question about H.248.19. > > Meanwhile. > > In H.248.19 defines vwp/wxp and vwp/wyp as being from 0 to 10000. > > The description text states: > This property is set by the MC to represent the horizontal "X" > position of the bottom left hand corner of a window. > 0 represents the left hand side of a screen, 10000 the right hand side > of a screen. > > So it makes the size of the screen equal to 10001 units. > > In the same time vwp/wh and vwp/wl are also defined to be 0 to 10000. > > I think it means that it is impossible to create window which fills > the entire screen. > (Screen is 10001 units and the biggest window is only 10000). [CHG] Given a display 10000 by 10000 pixels the way I saw the property working was that 0,0 represented the bottom left hand corner of the display/window. A window position 0,0 size 1,1 would draw a pixel 1,1 starting at this point. A window placed at 10000,10000 couldn't actually have a positive size as it would exceed the display. > > Do I misunderstand the description text? > Shouldn't the vwp/wxp and vwp/wyp be defined in range from 0 to 9999? > Or probably the range is OK, however the 10000 is outside of screen? [CHG] So technically 10000 is outside the meaningful range for displaying anything. > > What do you think? > ==================================================================== > > Another small editorial issue is that in H.248.19 on Figure 8 the text > references the vwpcvsp/ovs, where I believe it should be cvsp/ovs. [CHG] Is the editorial issue in Figure 8 itself? It should be cvsp/ovs but I can't see where the error occurs. > > > > Thanks, > Sasha > > > > > -----Original Message----- > From: Christian Groves [mailto:christian.groves@ericsson.com] > Sent: Thursday, June 16, 2005 8:55 PM > To: Sasha Ruditsky > Cc: itu-sg16(a)external.cisco.com > Subject: Re: The question about extension of an H.248 package. > > Hello Sasha, > > In thus case the text encoding would use H.248.15 Gateway control > protocol: SDP > H.248 package attribute. > > Regards, Christian > > Sasha Ruditsky wrote: > > >>Hi Christian >> >>Thanks. >> >>One more question. >>In H.248.19 most of the properties inside packages are specified to be > > >>"Defined in: Local/Remote". >>>From what I know about H.248 -- local/remote descriptors contain SDP >>messages. >> >>How do the H.248.19 properties coexist with SDP? >>Is it only possible in binary encoding mode? >> >>Thanks, >>Sasha >> >>-----Original Message----- >>From: Christian Groves [mailto:christian.groves@ERICSSON.COM] >>Sent: Thursday, June 16, 2005 12:35 AM >>To: Sasha Ruditsky >>Cc: itu-sg16(a)external.cisco.com >>Subject: Re: The question about extension of an H.248 package. >> >>Hello Sasha, >> >>There is no hard rule of what to propose. It really depends on the >>type of information you want added. >> >>I think the only time the package extension should be used is if the >>added properties/signals/events provide a set of functions of their >>own right. e.g. >>would it makes sense that these properties could be a package by >>themselves but need another package to operate. For example: The tone >>gen package. The DTMF was added as a extension package as DTMF >>generation is its own subset functionality but is related to the >>generation of tones. >> >>Regards, Christian >> >>Sasha Ruditsky wrote: >> >> >> >>>Hi >>> >>>I'm working on a proposal for July meeting to add some new properties >>>to one of the H.248.19 packages. >>>>From H.248 document it appears that there are defined (at least) two >>>ways of doing this. >>> >>>* Creating a new version of an existing package >>>* Creating a new package that extends the existing one. >>> >>> >>>Can somebody please comment on the factors helping to determine which >>>of these two mechanisms should be uses? >>> >>>Thanks, >>>Sasha >>>. >>> >> >> > >

1 0