World: r3wp

http://www.rebol.net/devcon/2005/photos/join-the-rebolution.jpeg

is that what's called "Viral Marketing"? :-)

Carl was curiously interested in BEER. Now the question is - was 
he trying to assure himself that LNS is good enough for most things 
even without BEER or was he mapping the situation to include BEER 
in REBOL? :-)

Whatever the situation is - LNS and BEER should start to think about 
supporting certificates ASAP!

Beer uses an api as outlined by Carl. So its one lns-implementation 
good enough to be published. Maybe the two could merge for the async 
daemon part.

http://www.colellachiara.com/devcon05/videos/Visitto Rome and Milan.mp4.torrent


Note: this is an experiment; encoded with avidemux on linux and converted 
from avi to mp4 with VLC. (iMovie wasn't producing a good quality 
result) play with VLC. (BitTorrent download - HTTP download available 
as soon as i finish uploading)

We talked about LNS on top of BEER. This would be an ideal combo

hmm, only if you are already using beer for something else. otherwise, 
beer doesn't give you anything more vs. lns on tcp or http

i mean, if you are using something like the apps demoed by jaime, 
then it may be useful to channel lns in the same connection too

if you are only using lns, it's much easier to just use tcp or http 
etc.

(http will let you go thru firewalls too)

I don't know the details yet, but my understanding is that BEER does 
a lot more in terms of transport then LNS. LNS needs a transport 
and BEER is much more advanced than basic Internet protocols

from beer-docs: The design has been inspired by rough draft about 
LNS protocol developed by Rebol Technologies.

But LNS is not a transport protocol

BEER does channelling in one single connection. if you don't need 
that, there's no advantage in using it vs. plain tcp. lns is doing 
its own auth/encryption and so on anyway.

So i hope most code could be exchanged and beer could be seen as 
just another lns-transport.

correct, beer is transport, like tcp or http

so you can have lns over tcp, http or beer

Yes, you can still use them separately. But they offer functionality 
on different levels

what i'm saying is that there's no real advantage in having lns over 
beer unless you are already using beer.

petr: LNS does not need to support "certificates" as it does not 
need SSL. actually, i don't see any reason for having SSL as a transport 
for LNS as it is already encrypted.

I think we're both saying the same. If you need BEER functionality, 
LNS is still good to have on top

yep.

And for LNS you need a transport, and this could be BEER

The point being that BEER is not an implementation of LNS, but that 
they're on different levels and augment eachother

As i see it beer is one way to use lns. cgi is another. Gabs lns 
too. Would it matter much that it is not build from Gabs lns code? 
I mean as Gab says - ah, you typed that already - i could even imagine 
lns over com if i need it from some windows app.

That's why I asked Carl about any overlap between them like authentication. 
He seemed to like the idea of combining them, too

depends on the additional features you get. and if this is arexx, 
this additional features, pluging into apps, is an lns-feature?

i mean getting features of non-lns-related apps by pluging in. using 
beer features, webserver features, whatever.

What is the status of LNS anyway?  Did I hear Carl say 90% ?

Last public announcement said live by may-2005:
http://www.rebol.com/news/rt5330.html
Perhaps you could ask via the RT Q&A

Gabriele - then you surely don't know, what I mean by certificates. 
And in fact - 1) RT's lack of support is quite weird indication of 
what the real world is using 2) not having SSL server mode as stated 
in Command docs in the last paragraph of "to do", is quite some limitation 
too ...

Gabriele - certificates do not have ANYTHING in common with SSL. 
and not understanding its role is fatal mistake for any rebol security 
related role. I have to say it so strongly, as I do work in that 
area for last two years ... I am far from being expert here, but 
I have enought experience to back up my solution - forget Rebol, 
if you will not be able to work with certificates.

solution =  opinion

As for lns development, I did a small lns emulation a while back 
based on published info. I found writing a service was easy, I think 
Gabriele demonstrated this well. I concluded that lns was a great 
idea, but there will be a learning curve of course. Reqesting the 
service from the client is a one-liner, but that is only the beginning 
of the story. Aside from the careful thought required in designing 
a service API, it will be interesting to see how people structure 
their client code because I think that is where the complexity of 
lns development could be from a programming point of view (e.g dealing 
with the service response).  Of course it depends on the application.

Pekr: There are so many "standards" that can vary by country, govt 
and industry, or platform. Can you specify which certification methodology 
you mean? is it x.509 ?

Allen: so many? :-) Where? Yes, X.509 of course. Simply put, to be 
able to work with certificates in OS or to have own container. Every 
browser can do it. It has nothing to do with security itself, it 
is about identity. You can be secure as much as you want, but there 
are parties which will not talk to you, if your server/user/customer 
is not clearly identified ...

this is an area where I see Rebol, either built-in or as an third-party 
addon, needs to support 'standard'

yeksoon - mostly whole EU, e.g. to do electronic invoicing, needs 
qualitified (not even commercial) certificates produced by some reliable 
Certification Authority. What is more, such certificates do expire 
in one year. For such invoices to be valid, you need kind of "long-term 
archive", you need simply to re-sign them. So you typically go and 
use so called time-stamps (kind of certificates), provided by CA 
once again ....

Petr: i'm sorry, but it's you who are confusing certificates and 
SSL. there is absolutely nothing preventing you to parse certificate 
files, in any format; i really don't understand what kind of "support" 
do you need.

Gabriele - "LNS does not need to support "certificates" as it does 
not need SSL" - was was it me or you ;-)

In regards to SSL I only rephrased, that somehow by-the-way, there 
was once plan for better support even in that area - just look at 
the last paragraph of Command SSL doc :-)

And as for certificates - here we go once again - you have parser, 
you can study standards, you can implement everything yourself. Now 
I would like to remind you, that I am not here to actually come-up 
with some solution, especially in the case when I am not skilled 
enough to produce one myself, but I want to use some solution out-of-the-box.

It is all about - you can do it with rebol, or you can't. Talk "enablers" 
once again. Do you think that ppl look at tools to actually produce 
some support first, or they simply want to use it for the task given. 
One example - someone wants to use PostGress for e.g. Now he is looking 
for some tool, eventually likes rebol. There is a BIG difference 
if such person is about to just do %postgress-driver.r and connect 
and use it, or to actually spend months producing the driver on his/her 
own.

I mentioned certificates for two reasons here. 1) IIRC Holger (or 
someone from RT, do not remember right now) said, that internally 
Rebol has some parser for that, but the API for that is not exposed 
2) it seems to me, that there might be some parts of the world, where 
encryption is enough, and there is nothing bad with such opinion, 
in regards to such countries ...

Now let me explain 2):

We are one of the first companies here in CZ, who try to fully solve 
electronic invoicing. In order to not need a paper, our law (and 
many EU countries too), simply require usage of certificates. It 
has nothing to do with how secure your transfer is. Simply once financial 
institute clerk comes to our company, he wants to see original invoices. 
And so far, it is paper. And if it is e.g. PDF, it has to be signed, 
as the person will ask - how can I be sure, it comes from company 
XY? He can - he can check e-signature and time-stamps signatures 
and he can be sure, that 1) the invoice comes from company (identity) 
XY and that it was not later modified, or the e-signatures would 
be invalid ...

now to be more constructive - Gabriele, is there any chance, that 
if I write down my requirements, RT can outline how much would it 
cost to bring certificates to rebol? :-) I do not know how much, 
but maybe 1000 EUR could be spent by our company to have it available. 
It is not much, but l expect discount, if I let RT to provide result 
to the community :-)

I expect that in some way the code is inside already. The trouble 
also is with /Command. Today security should not be luxury but default. 
If I understand it correctly, even BEER uses cloaking in order for 
BEER to be usable by everyone. Now it is the question, if such certificate 
support would be available only to /Pro /Command and /SDK users, 
or ...

maybe I should post my request in RT Q&A group ...