Hi Jayanth,
If iCAP is "after all" a candidate proposal, why should it feature
in the charter?
It's not clear whether there will be a single callout protocol solving
all requirements in all possible scenarios (e.g. classical web
traffic, streaming, etc.). Therefroe, OPES might have to design a
framework into which multiple different callout protocols "snap in". I
believe it's very important to have this flexibility.
iCAP is one existing callout protocol and has been implemented by
various folks. The experience gained from this work (good and bad)
provides valuable feedback for future OPES protocol work. Furthermore,
it would be interesting to see whether and how a protocol like iCAP
could "snap into" the OPES framework. This does NOT mean to rubber
stamp iCAP and does NOT prevent alternative and/or complementary
solutions.
Now, whether and how this is reflected in the charter...
Maybe we can say "authentication and authorization mechanism"
instead of "authorization mechanism"
in the last line.
Yup, I would agree to that.
Maybe I am understanding something wrong here, but the use of the
term "encapsulated" misleads
me....we are talkning about protocols that enable the exchange of
HTTP and RTP/RTSP messages.
that need to be modified ...right ?
You're, this might be confusing. We're talking about protocols that
enable exchange of HTTP and RTP/RTSP messages, possibly by
encapsulating them.
Thanks for your comments.
-Markus