If you are going to mandate-off someting, it is surely better to keep the
general XML stuff in an mandate-off the exception. Mandate-off the use
of (unescaped) <?eom?> directive within the data. This way advanced
uses have advanced work to do (un/escaping) and simple uses can take it simply
(scan frames on <?eom?> markers).
Thanks
P.S. The framing constructs should never use the same syntactic conventions as
the data it frames...
-----Original Message-----
From: Ed Roskos [mailto:ed.roskos@utstar.com]
Sent: Thursday, February 19, 2004 5:10 PM
To: Wes Hardaker
Cc: tstoddar@utstar.com; 'Juergen Schoenwaelder'; netconf@ops.ietf.org
Subject: Re: Issue 5.1) SSH End of message directive
>>>>>>On Thu, 19 Feb 2004 16:37:09 -0500, Ed Roskos
>>>>>><ed.roskos@utstar.com> said:
>
>
>>>Consider a user with the ability to change
>>>just one string somewhere (say his name for his account). If he
>>>changes his name to John <?EOM?> Doe, what will parsers do?
>
>
> Ed> That was a scarey throught at first =) But I guess that the
> Ed> parsers and renders need to translate '<' to < and '>' to >,
> Ed> else you have problems no matter what. The text content needs to
> Ed> translate the (I think) 5 standard entities on rendering, and
> Ed> parsers auto-convert them when parsing.
>
> Yeah, but isn't that not true in CDATA related sections which is
> bounded by a different special delimiter?
>
> I'm not an XML expert, so forgive me if I'm wrong.
Yeah, actually you are right, on input, someone could use
a CDATA section. But one of two things would happen from here: either (1) the framer catches the text and the XML parse of the input document fails and nothings happens, or (2) the framer doesn't catch it and the data are stored as is.
On output, I was assuming, being a developer, that others would avoid rendering with CDATA blocks.
Should we recommend/mandate we not use CDATA blocks on output?
--
to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>