Subject: RE: [Megaco] The ABNF coding of VALUE doesn't allow to representageneric UTF-8 string/char

From: "Steve Cipolli" <[email-masked]>
Date: Wed, 29 Jun 2005 10:16:23 -0400

Sasha Ruditski from RADVISION is putting together a contribution for
adding UTF-8 characters 0x80-0xFF (technically only 0x80-0xF7 according
to the rules of UTF-8)
 
The other two issues:
    1. Support for escaping double quotes (0x22) in quoted VALUE strings
and
    2. Support for non-printable characters in the range 0x01-0x19
should be handled in separate contributions.
 
Issue #1 makes sense to me to be included in v3.  
 
Issue #2 is less clear. to me.  I'm not sure it is worth the effort, or
if instead the package definition text should simply be changed to say
"printable UTF-8 characters (0x20-0xFF)" for all encodings.  My
reasoning is that even if we add 0x01-0x19 to VALUE we still will not be
able to transmit UTF-8 character 0x00 in ABNF, so the blanket statement
that says all UTF-8 characters are supported would still not be true.
 
--Stephen

	-----Original Message-----
	From: Kevin Boyle [mailto:[email-masked]] 
	Sent: Tuesday, June 28, 2005 4:12 PM
	To: Contardi Angelo; Steve Cipolli; Megaco IETF - Mail List
(E-mail)
	Cc: Christian Groves (E-mail)
	Subject: RE: [Megaco] The ABNF coding of VALUE doesn't allow to
representageneric UTF-8 string/char

	I will note that H.248.23 also has avoided this problem by
encoding the data in hex.  This, along with the solution in .9, provides
examples of two possible solutions to both problems.

	You continue to point out that ASN.1 doesn't have this problem.
That is because ASN.1 uses the hex encoding, and can avoid some of the
end of string detection problems that ABNF inherently possesses.  .23
uses this same idea -- hex encoding in the ABNF allows explicit
detection of the end of the value string without adding a collision with
the delimiters.

	Steve makes some good points about the fact that the upper half
of UTF-8 does not collide with the delimiter, and therefore shouldn't be
a problem.  I have no problem with this as a solution.  A contribution
should be taken to SG16 for this proposal.

	Kevin 

	[Snip...]

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco