ietf-mxcomp
[Top] [All Lists]

Comments on draft-ietf-marid-core-01 xml use

2004-06-02 21:20:55

The method for publishing definitions for XML using a DNS TXT record can
be extremely verbose.  Removal of any size considerations in this draft
such as keeping the query/response under 512 bytes is unfortunate.
  
The header defined for this DNS TXT record should be stand alone.  This
would simplify processing of the information as it would safe from being
overridden by external declarations.  In other words, the entire
definition for the structure of the record would be a single document
and described as:

<?xml version="1.0" standalone='yes' encoding="US-ASCII"?>
<root 'all definitions'> 
<ep>
...  <!TXT record portion>
<\ep>
<\root>

The entire definition would be encompassed by this single document and
would not reference external definitions.  This would then curtail new
definitions without a required revision of the specification redefining
the record.  This standalone requirement will dramatically lower a
revision churn rate for software used to interpret these records and
simplify the processing of the information.  Otherwise, this could lead
to serious incompatibilities.  As this is 'virtually' concatenated,
brevity of the prefix is not an issue either.

The TXT record could begin _MARID-1 for future collision avoidance where
everything following this token is appended with a prefix and suffix
specified by the standard supplanting the token.  Only information
formatted according to these definitions would need placed within the
TXT record following the token.  The concatenation of the prefix and
suffix header to the record was not well demonstrated from 5.3.1 in
5.3.2.

The advantage found defining the structural information in this manner
saves precious space alloted in a DNS packet response and ensures that
code complied to interpret this record will not be impacted by new
definitions created outside the standards effort.  Declaring IANA
responsible for the urn namespace marid-? offers little assurance other
outside references will not be included as otherwise allowed by XML. 
The total definition for this record should complete and bound to this
specification as a single standalone document.

In addition, specifying a multi-byte 8-bit character set could be a
problem for tools expecting 7-bit ASCII.  All UTF-8 characters > 0x7F
are encoded as a sequence of bytes with the most significant bit set. 
Why the departure from ASCII?

-Doug