Subject: [BEEPwg] Questions about RFC 3080 (and then 3195)

From: [email-masked]
Date: Mon, 11 Mar 2002 10:52:09 -0600

We are going to use BEEP to send reliable syslog messages for medical
imaging systems (CT scanners, image archives). I could use some help in
making sure I understand how this works. If the questions about Reliable
Syslog
should go to another forum, please point me in the proper direction.

1. We are going to use TLS. Is this how this works?
- Initiator/listener exchange greeting messages
- Initiator sends a start message with the profile
  <profile uri='http://iana.org/beep/TLS'>
- Listener sends RPY message and says to proceed
- TLS negotiation occurs on the open socket. This is
not encapsulated in BEEP; it just occurs at the socket level
- After TLS negotiation, initiator and listener exchange
greeting messages again. These include different
profiles, now that we are using TLS encryption.
- Initiator would send a new start message, listener
would reply, and off we go

2. This is probably a rewording of #1, but I need to be certain.
When TLS is used (and operational), I assume it is the next
layer above the socket layer. That is, the BEEP messages are
then sent through a TLS encapsulated stream.

3. This would imply that for a session, you can only have a single
encryption scheme active at a time. That is, you can have
multiple channels open, but they will all use the single encryption
scheme that was negotiated up front. (Yes/no)?

4. Now, I will drift into RFC 3195. The listener wants to support
the COOKED mode of syslog. I think the exchange works something
like this:
- After the socket is first opened, listener sends a greeting message
with the (one) profile http://iana.org/beep/TLS. Initiator sends greeting
message as always.
- After initiator sends the start message, TLS negotiation occurs.
- Listener now sends a greeting message with a profile
  http://xml.resource.org/profiles/syslog/COOKED.
- Initiator sends greeting message (possibly before listener does).
- Initiator sends a start message with that profile (COOKED), listener
sends
the RPY message and then the exchange of syslog messages
starts.
Do I have this correct?

5. Our group has defined further the content of the syslog messages.
They are not just plain text, but are expressed in XML. So we use
the syslog wrapper, but add our own XML. Does this look like this?
     <entry facility='160' severity='6' (other things deleted) >
     { My XML}
     </entry>

5.1 If the messages have the format as described above, is the text
for {My XML} just pasted in as XML
     <Tag 1> Value1</Tag1>
Or do I have to "escape" this somehow (sorry, not an XML expert either)?

5.2 If I can figure out how the XML encoding works, does this mean that
I still use the profile 'http://xml.resource.org/profiles/syslog/COOKED
or does our group have to define a new profile

Thanks in advance for your help,

Steve Moore
Washington University School of Medicine

_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg

---

From: Darren New <[email-masked]>
Date: Mon, 11 Mar 2002 11:04:59 -0800

> should go to another forum, please point me in the proper direction.

The syslog-reliable working group has a mailing list, too.

> would reply, and off we go

Correct.
 
> then sent through a TLS encapsulated stream.

Correct.
 
> scheme that was negotiated up front. (Yes/no)?

Correct.

> the RPY message and then the exchange of syslog messages

Yes. In RAW mode, the "exchange of syslog messages" is different, but
yes.

Note that in COOKED mode, each syslog message sent is answered with
<ok/>. You can't have syslog messages going both directions on the same
channel. You can open a second channel in the other direction if you
want bidirectional syslog messages.
 
>      <entry facility='160' severity='6' (other things deleted) >

That would do, yes.
 
> Or do I have to "escape" this somehow (sorry, not an XML expert either)?

You have to escape it. The <!ELEMENT entry (#PCDATA)> in the DTD means
that
only "parsed character data" may occur there. Hence, since it's parsed,
you
need to escape (&lt;) any less-than signs in the data. Grok the data in
the first couple of examples in 4.4.2.

> or does our group have to define a new profile

It shouldn't be a problem to use this, if your XML records are small
enough. Of course, standard relays and such won't understand what's
inside the data, but a custom collector should be able to.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
  To the user, everything works just as expected,
    assuming the user's expectations are correct.
_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg