[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 5.1) SSH End of message directive
HI,
Ed, you are not correct on your PS with BEEP. Since with BEEP,
it chunks (segments) the message, you do not need to build a
complete
message before starting to send. The BEEP layer does the chunking
both on input and output for you. You just write or read a stream
of octets. Of course, having a person doing the chunking is not
fun. However, marshall rose wrote a gui app in which you type or
paste
text and it does the BEEP work for you. (I don't know the status
of the gui app.)
At 09:15 AM 2/20/2004 -0500, Gilbert Gagnon wrote:
Hello,
It may be just a bit overkill but it might be a good idea to suggest a
common escaping for cases within the CDATA block (e.g. user the </%gt;
entities even though they are within an escaped block). The rationale is that
since mixed contents (tags and plain text values) is discourage (I like that)
it would be difficult to put some CDATA stuff, then close this to put the
EOM with entities outside of the block, then open up another CDATA block
to complete the text value that was originally intended.
Again, it might be a bit beyond the essential but it does not sound
costly to suggest and it sticks to the principle that only specialized
used of the system would need to do specialized processing.
Thanks
P.S. As I P.S.ed I do prefer length encoding for framing but if used blindly
(as in plain HTTP), it forces one to construct the entire output (in memory)
before sending it at great latency and memory costs (on element and manager)
in order to know the length to put it in the frame header. To work, that
requires true framing/fragmentation and incremental parsers. THat's
something that's been on my mind with NetConf (e.g. a large show config)
since the first time I saw it. In the end, the scripting requirements
are not completely similar to the 24/7 management protocol requirements...
[ignore me if you've discussed this before, I'm new on the list though not
to the protocol...]
-----Original Message-----
From: Ed Roskos [mailto:ed.roskos@utstar.com]
Sent: Thursday, February 19, 2004 8:37 PM
To: Wes Hardaker
Cc: Gagnon, Gilbert [CAR:NM10:EXCH]; tstoddar@utstar.com; 'Juergen Schoenwaelder'; netconf@ops.ietf.org
Subject: Re: Issue 5.1) SSH End of message directive
Wes Hardaker wrote:
>>>>>>On Thu, 19 Feb 2004 20:02:52 -0500, Ed Roskos
>>>>>><ed.roskos@utstar.com> said:
>
>
> Ed> But SSH, as I see it, must fill a particular need, and that is
> Ed> scripting. How do you explain to someone that they cannot just
> Ed> cut-and-paste, they must calculate bytes for the message, while
> Ed> they are playing around getting their scripts right in the first
> Ed> pass?
>
> Oh, sorry if you thought I was advocating byte counters. I wasn't. I
> was just pointing out there are two ways to get around problems like
> this: forced escaping and byte lengths.
>
> Note that BEEP has byte length counters in it as well, which I've
> pointed out before because I wasn't sure script-writers would want it.
I would advocate something byte-counters for non-scripting interfaces. Haven't played with BEEP yet, but I can't wait. Cool stuff =)
> Ed> What we need for SSH is a simple way to stream in your messages
> Ed> which does not introduce possible security breaches. I think we
> Ed> pretty much have such a method.
>
> Which is? disallowing CDATA? That'd be unpopular I bet.
Nah, disallowing CDATA was killing a fly with a nuke. Gilbert had a far better idea. If you use CDATA with the SSH protocol, just make sure you don't do so with the EOM marker on output, which implementers should be able to do pretty easily.
To see if we have the bases covered with this approach, here are the ideas again (correct me if I'm wrong!):
On input if the user chooses to use CDATA on input with the EOM marker, an implementation would wind up doing one of two things. Either it recognizes it is inside of a CDATA section and handles it correctly, or it does not recognize this, falsely identifies the end-of-message, and a syntax error occurs resulting in no update.
On output, we just have to be sure that we do not render the end-of-message text verbatim. This can only happen in a CDATA section, AFAIK. You can always render with < and > outside of a CDATA block. Since an XML parser will pull in text after stripping out the CDATA syntax and converting escaped characters in non-CDATA text, you would never know the difference, and the framing by a script writer will work.