[Ndb] Summation to MITRE Question

[Sam Buckwalter]

Hello All:

The below email contains the summation of all the responses received from David Baker question.

========================================================
We’re happy with US-ASCII.

Regards,
Navtech


========================================================================

We don’t see any compelling reason to move away from the XML standard of UTF-8.

I would be concerned with unintended consequences such as possibly limiting the availability/usability of off-the-shelf XML tools.

We already check for valid characters within our packing program which I’m sure other FMS vendors do as well.

Thanks


-          GE

=================================================================================================================
We are not huge into the XML at this point, but we have seen similar problems when dealing with source data from various suppliers around the world.  It greatly complicates processing.  Since all of Garmin’s avionics (and I suspect, most avionics in general) are not set up to display such special characters, our vote would be to go with US-ASCII.

Thanks,
Garmin


===============================================================================================
Hello David,
            High levels of data integrity and data assurance are prime motivators to us to ensure secure transmission of aeronautical data.  Based upon your findings, we would not want to limit our format to UTF-8.  US-ASCII would work for us – we have not yet developed any applications to ingest this data, so we would be starting with a clean slate.  I’m sure there are other formats that would also be feasible.
            In your example, it appears a SDK already exists, or could exist (the UML software vendor provided me a script).  If so, this should be a consideration for everyone exploring the use of 424A.
Respectfully,


BAE Systems


====================================================================================================
All,

I agree that the existing ARINC 424 fields should stay limited to the existing character set of alpha / alphanum. The standard way to do so in XML are XML-Restrictions, e.g.
<xs:element name="letter">
  <xs:simpleType>
    <xs:restriction base="xs:string">
      <xs:pattern value="([a-z][A-Z] [0-9])* "/>
    </xs:restriction>
  </xs:simpleType>
</xs:element>

One important goal of 424A is the easier extensibility of the standard in the future. One such extension may be text notes, and some customers may like to see them in their native language (Cyrillic, Chinese, Thai…). I don’t want to completely preclude this option.

Jeppesen

From: ndb-bounces at mailman.sae-itc.org<mailto:ndb-bounces at mailman.sae-itc.org> [mailto:ndb-bounces at mailman.sae-itc.org] On Behalf Of Sam Buckwalter
Sent: Wednesday, January 14, 2015 15:48
To: 'NDB at mailman.sae-itc.org'
Subject: [Ndb] FW: NDB Committee Question

NDBer’s:

Please read David’s email below and provide comment.

Thanks

Sam Buckwalter
Program Director

ARINC Industry Activities
An SAE ITC Industry Program
16701 Melford Blvd., Suite 120
Bowie, MD 20715

c  +1.443.454.0584
 sbuckwalter at sae-itc.org<mailto:sbuckwalter at sae-itc.org>
www.aviation-ia.com<http://www.aviation-ia.com/>



From: Baker Jr., David E [mailto:dbaker at mitre.org]
Sent: Wednesday, January 14, 2015 8:21 AM
To: Sam Buckwalter
Subject: NDB Committee Question

Sam,

This is the question to ask the group.

Background:  The 424A XML format will define a standard character encoding.  Right now we are using the default of UTF-8 some might know this as Unicode.  Unicode allows for a wide range of international non-English characters.  However, Unicode will make the 424A standard less secure as there are many characters across the world that are very similar, and can be used to spoof people.  For example, I inserted these characters that all look very similar to the letter ‘o’ oŏōơȯʘοϘϙ.  In short, Unicode makes the 424A standard less secure than 424.

Question:  Do we need UTF-8, if not is the group happy with the character encoding being “US-ASCII”?  This will require the use of a script to create the XML schemas from the UML model, however the UML software vendor provided me a script to do this.

Impact:  Limit the allowable characters in one clean move.  Requires a script to generate the XML schemas.  Requires the ultimate, corporate, and/or software engineering version of Sparx EA.

David E. Baker Jr.
Systems Engineer
MITRE Corporation, Bedford Ma
781-271-4779



Nothing in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message. Confidentiality Note: This message is intended only for the person or entity to which it is addressed. It may contain confidential and/or proprietary material. Any review, transmission, dissemination or other use, or taking of any action in reliance upon this message by persons or entities other than the intended recipient is prohibited. If you received this message in error, please contact the sender and delete it from your computer.


Nothing in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message. Confidentiality Note: This message is intended only for the person or entity to which it is addressed. It may contain confidential and/or proprietary material. Any review, transmission, dissemination or other use, or taking of any action in reliance upon this message by persons or entities other than the intended recipient is prohibited. If you received this message in error, please contact the sender and delete it from your computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.sae-itc.org/pipermail/ndb/attachments/20150116/3cbf8317/attachment-0001.html>