Subject: RE: Start on OPES protocol work

From: "Abbie Barbir" <[email-masked]>
Date: Tue, 18 Feb 2003 05:39:00 -0500

MArtin,

for BEEP check,

http://beepcore.org/beepcore/specsdocs.jsp

http://www-106.ibm.com/developerworks/xml/library/x-beep2.html

http://www-106.ibm.com/developerworks/xml/library/x-beep/index.html

abbie

> -----Original Message-----
> From: Martin Stecher [mailto:[email-masked]] 
> Sent: Monday, February 17, 2003 5:41 AM
> To: The Purple Streak, Hilarie Orman
> Cc: [email-masked]
> Subject: RE: Start on OPES protocol work
> 
> 
> 
> Hi Hilarie,
> 
> > 
> > 1. I believe that the protocol requirements stipulate the use of 
> > independent "channels", and those were put in exactly for 
> the the case 
> > you are discussing for preview.  If channels don't solve 
> the problem, 
> > we need to know why.
> 
> draft-ietf-opes-protocol-reqs-03 does not mention the 
> "channels", does it? Till this weekend I was not aware that 
> the "channels" concept already implies that each fragment of 
> an application message is sent in its own callout message via 
> the channel. Is this correct? If yes, I appreciate this 
> concept very much and I think it is exactly what I thought 
> about solving the out-of-sync and preview problems.
> 
> 
> > 
> > 2. For the SMTP case, let's suppose that the site policy
> > requires virus
> > scanning, but some subscribers to the OPES box want 
> potential viruses
> > removed, and some simply want them flagged.  Assume a 
> message has been
> > sent to several recipients of a domain with an OPES virus scanning
> > service, and its body is denoted as "A" (identified by its hash, I
> > suppose).  If it's the OPES processor that holds the user 
> preferences,
> > then it can handle the process of sending A to a callout server for
> > virus scanning and asking for both removal and flagging, possibly in
> > one request, but at worst in two.  Ah, I see, you'd like to 
> eliminate
> > the two requests, and have a request type that asks for multiple
> > services and multiple replies.  This is different from asking for
> > multiple services and one reply.  A notation for this might 
> > be something
> > like:
> > 
> >   Request(data=D; service=A AND service=B)
> >   Reply(data=A(B(D)))
> > 
> >   Request(data=D; service=A; service=B)
> >   Reply(data=A(D); data=B(D))
> > 
> > Have I captured the requirement correctly?
> 
> I am not sure. Please have a look into my posting "SMTP 
> filtering use case".
> 
> > 
> > 3. I know the arguments for simple formats, but please give 
> something 
> > specific about your objection to BEEP.  My objection to XML 
> encoding 
> > is that it requires many instructions to parse it into tag 
> pairs and 
> > parameters, to create a parse tree, and to traverse the tree.  When 
> > comparing this to direct indexing, or even scans for end-of-header, 
> > end-of-line, XML is very slow.  But, experience has shown 
> that there 
> > are distinct limits to what can be accomplished with fixed 
> parameters 
> > positions and bit encodings, and even TCP has had a great deal of 
> > trouble staying within its header limitations.  Up at the 
> application 
> > layer, I think some compromise will be necessary.  I'd thought BEEP
> > was actually
> > a good point to begin looking for that compromise point.  What is so
> > awful about it?
> 
> 
> I am really sorry that I started to name protocols. I didn't 
> want to get into this discussion now. On the other hand it 
> shows that existing protocols have interesting concepts that 
> are very worth to be known and understood while discussing 
> OPES protocol needs and I doubt that I would really look in 
> the protocol's details without this discussion.
> 
> Unfortunately I had only a brief look into RFC 3080 (BEEP 
> core) before sending my first message last week. And in there 
> I found all examples full of XML structure, always repeating 
> same Content-Type header with every single small message and 
> that little PASCAL reminding "END" literal.
> 
> So on my first glance it did not look very efficient to me.
> I thought that if each application message's fragment is 
> encapsulated in its own BEEP message this would be a big 
> overhead. Seems that this is not so.
> 
> By learning a little more about it over the weekend and 
> starting to understand the "channels" concept, I agree that 
> BEEP is very worth to be considered. It is not "awful" (and I 
> never said so).
> 
> But still we should not elect the one or other protocol now. 
> What we rather need is a common understanding about the best 
> concepts and how they could fulfill the requirements and 
> solve the questions and problems that we list.
> 
> What other BEEP documents than RFC 3080 should be studied?
> Is there a good summary about the concepts that could help 
> OPES? If not, could somebody compile one?
> 
> 
> Martin
> 
> 
>

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 18 Feb 2003 09:01:44 -0700 (MST)

> http://www-106.ibm.com/developerworks/xml/library/x-beep/index.html

My understanding is that supporting BEEP requires supporting XML
because <start>, <greeting>, <profile>, and other XML elements have to
be supported. Please correct me if I am wrong! I just want to make
sure that XML-enemies know that BEEP relies on XML...

It is possible to limit XML support to rigid parsing of the few
documented elements (we have done that in Web Polygraph benchmark, for
example). However, such limited support is the "wrong thing to do"
in general and is likely to cause compatibility problems in the future.

Alex.