ietf-openproxy
[Top] [All Lists]

RE: Start on OPES protocol work

2003-02-18 03:39:10

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:martin(_dot_)stecher(_at_)webwasher(_dot_)com] 
Sent: Monday, February 17, 2003 5:41 AM
To: The Purple Streak, Hilarie Orman
Cc: ietf-openproxy(_at_)imc(_dot_)org
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



<Prev in Thread] Current Thread [Next in Thread>