ietf-mxcomp
[Top] [All Lists]

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

2004-06-03 13:39:10

In his comments, Doug makes several points, which I summarize and
respond to as follows:  (If I mis-interpreted any of them, I'm sure Doug
will chime in.)


1.  [Doug] 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.

I believe that it will be easy for publishers to keep their DNS
responses under 512 bytes.  I would be happy to add a RECOMMENDATION to
the document that publishers do so.


2.  [Doug]  The document should be standalone (in the sense of <?xml
standalone="yes"?>).

I'm not sure how the standalone declaration interacts with XML schemas.
I'll find out.  (It pre-dates the whole schema effort by a few years,
and specifies that all of the XML DTD info is present in the document.
Given that none of the MARID docs can have DTDs, this is vacuously
true.)


3.  [Doug] Other words about standaloneness, implying (I think) that
implementations shouldn't be required to load arbitrary schemas to
understand a document.

I completely agree with the goal.  I would expect an implementation to
have those schemas that it understands (initially just ...:marid-1)
hard-coded into it.  By explicit words in the spec, an implementation is
required to ignore elements and attributes whose schema it doesn't
understand.  It need not search to find a schema document for other
namesapces, it can just ignore the elements.


4.  [Doug] We should require that a conforming document never have any
references to a namespace other than ...:marid-1 (or possibly
...:marid-*).

Allowing references to as-yet-undefined namespaces is an important part
of the extensibility.  As extensions are defined, it allows publishers
to write documents using the new extensions, yet remain compliant with
the current version.  Without this, it would be suicidal for a publisher
to take advantage of a new extension -- his document would be seen as
invalid by any implementation that hadn't yet been updated to understand
the extension.


5.  [Doug] The wrapping added to the DNS record to get the XML document
should include the <ep> and </ep> tags.

I intentionally didn't do this (at the cost of 9 bytes), to allow for
the possibility of adding attributes to the <ep> tag.  For example, the
possibility of <ep testing="true">.  If we don't want this possibility,
I would just as soon make the <ep> tag go away completely.


6.  [Doug] Why does the document say "UTF-8" instead of "US-ASCII"?

By specifying UTF-8, the spec says exactly what should be done with
characters whose high bit is set.  However, given that some DNS
resolvers may (incorrectly) treat records containing non-ASCII
characters as malformed, I would be happy to add a RECOMMENDATION to the
document that publishers should avoid non-ASCII characters in their
documents. (Note that if you include only ASCII characters, it's
automatically valid UTF-8.)


-- Jim Lyon