ETSI's Bug Tracker - Part 11: Using JSON with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007914Part 11: Using JSON with TTCN-3[TTCN-3 Change Requests] Editorialpublic05-03-2020 06:0823-12-2020 13:59
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV4.8.1 (published 2020-05) 
Target VersionV4.9.1 (ongoing)Fixed in VersionV4.9.1 (ongoing) 
Summary0007914: conflicting definition and examples for usi encoding
DescriptionSection B.3.7 clearly states that using the "escape as usi" encoding instruction, all characters in the TTCN-3 value shall be encoded using the USI-like escape sequence "\u<HHHH>"

Yet the example for "escape as usi" in section 6.4.2 clearly show that only special characters need to encoded like that.
None of the examples uses the \u<HHHH> format for the abcd letters.
Steps To Reproduce
Additional InformationI was looking at version v4.8.1 (2018-05)
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7914.docx (150,351) 06-10-2020 11:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3956&type=bug
docx CR_7914_v2.docx (150,303) 08-10-2020 14:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3960&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-03-2020 06:08Kristóf SzabadosNew Issue
10-08-2020 11:02Jens GrabowskiAssigned To => Kristóf Szabados
10-08-2020 11:02Jens GrabowskiStatusnew => assigned
24-08-2020 11:31Gyorgy RethyNote Added: 0015753
06-10-2020 11:08Kristóf SzabadosFile Added: CR_7914.docx
06-10-2020 11:09Kristóf SzabadosNote Added: 0015759
06-10-2020 13:47Jens GrabowskiAssigned ToKristóf Szabados => Jacob Wieland - Spirent
06-10-2020 14:15Jacob Wieland - SpirentNote Added: 0015762
06-10-2020 14:16Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
08-10-2020 14:35Kristóf SzabadosFile Added: CR_7914_v2.docx
08-10-2020 14:35Kristóf SzabadosNote Added: 0015781
08-10-2020 14:36Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
08-10-2020 14:36Kristóf SzabadosStatusassigned => confirmed
08-10-2020 15:43Jacob Wieland - SpirentNote Added: 0015783
08-10-2020 15:43Jacob Wieland - SpirentStatusconfirmed => resolved
08-10-2020 15:43Jacob Wieland - SpirentResolutionopen => fixed
08-10-2020 15:43Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
17-12-2020 14:30Gyorgy RethyNote Added: 0015883
17-12-2020 14:30Gyorgy RethyStatusresolved => closed
17-12-2020 14:30Gyorgy RethyFixed in Version => V4.9.1 (ongoing)
17-12-2020 14:30Gyorgy RethyTarget Version => V4.9.1 (ongoing)
23-12-2020 13:59Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
23-12-2020 13:59Jens GrabowskiStatusclosed => assigned
23-12-2020 13:59Jens GrabowskiStatusassigned => closed

Notes
(0015753)
Gyorgy Rethy   
24-08-2020 11:31   
Actually, I think clause 6.4.2 is correct and B.3.7 should be amended. The intension of the encoding instruction is not forcing the replacement of "normal" characters with their escape codes, but rather enable to control which way of escaping to use, IF a character is being escaped.

BUT, to provide a backward compatible correction, tool implementations should be checked and choose the solution, which majority of the tools support.
(0015759)
Kristóf Szabados   
06-10-2020 11:09   
Uploaded initial proposal.
(0015762)
Jacob Wieland - Spirent   
06-10-2020 14:15   
I would also think that only those characters that MUST be escaped should be escaped:

From the standard:

except for the characters that must be escaped:
   quotation mark, reverse solidus, and the control characters (U+0000
   through U+001F)
(0015781)
Kristóf Szabados   
08-10-2020 14:35   
re-phrased accordingly. Please check.
(0015783)
Jacob Wieland - Spirent   
08-10-2020 15:43   
fine with me
(0015883)
Gyorgy Rethy   
17-12-2020 14:30   
Implemented in draft 4.8.2