I'm not quite sure it's correct that these issues don't arise with XML 1.0
(although I agree life will be easier if it is true).
Issues regarding the BOM are rife with XML 1.0 because UTF-16 is a
recommended charset, and beep supports its use.
RFC 2396 defines that the semantics of a fragment identifier are a property
of the data resulting from the retrieval action, so arguably RFC 2048 should
be updated to have MIME registrations explicitly define those semantics.
You can leave them undefined, but there is some value from supporting
XPointer.
XML Base is an optional enhancement for XML 1.0 that can change the
interpretation of relative URLs. You can support it, explicitly not support
it (by outlawing relative URL), or leave it undefined.
So, again, feel free to ignore; I just wanted to make sure the issues are
clear.
- dan
--
Dan Kohn <mailto:dan(_at_)dankohn(_dot_)com>
<http://www.dankohn.com> <tel:+1-650-327-2600>
-----Original Message-----
From: Marshall Rose [mailto:mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us]
Sent: Tuesday, 2000-10-24 10:13
To: Dan Kohn
Cc: bxxpwg(_at_)invisibleworlds(_dot_)com; ietf-xml-mime(_at_)imc(_dot_)org;
mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us
Subject: Re: [BXXPwg] application/beep+xml
Marshall, my only question is whether some of the Security Considerations
of
<http://www.imc.org/draft-murata-xml> additionally apply. Since you are
prohibiting the use of external entities, you avoid most of the risks,
however there is still the possibility of someone parsing the data with a
standard XML processor. Also, you might explicitly want to mention
whether
this type follows RFC 2376bis's advice on use of the BOM (section 4),
XPointer syntax (section 5), and Base URI (section 6). Or, you could just
leave these things undefined.
hi. i think you're missing the point. the particular subset listed there
excludes all of the things you are mentioning. they aren't in the 1.0
specification. hence the addition text you request is redundant. that's
sort of the whole point.
/mtr