World: r4wp

The fact is that, e.g., "0.1" is not accurate when you *want* 17 
digits of the number, but it is "accurate enough" when my definition 
of what "accurate enough" means is used.

In the same way, "0.10000000000000001" is not exact when you need 
to know how exactly the number looks, but it is again "accurate enough".

Why are you trying to push this change into MOLD without /all?

 - aha, this may be a misunderstanding. I am not that far yet. What 
 I said was that it was possible to define which string may be considered 
 "accurate enough" when representing a given Rebol value VALUE. There 
 may be more than one such string. Now it is interesting that neither 
 MOLD nor MOLD/ALL needs a longer string than the one that is already 
 "accurate enough". Thus, it might make sense to just use the shortest 
 "accurate enough" string (which may have even less than 15 digits) 
 for both MOLD and MOLD/ALL..

I see this described behaviour as the most "intelligent one" because 
it gives the "accurate enough" result, while the current (in Windows, 
that is) behaviour of MOLD is that many of its results are not "accurate 
enough" while some of the MOLD/ALL results are longer than necessary 
for being "accurate enough". Interestingly, it seems to me that e.g. 
Rebol 2.100.111.2.4 already has MOLD/ALL working this way.

err. it probably was 2.100.111.4.4

History of the problem: the whole issue originated when we found 
out that MOLD was not "accurate enough". I proposed to use a sufficient 
MOLD with 17-digit precision, which was made available by introducing 
SYSTEM/OPTIONS/DECIMAL-DIGITS, but that still did not look to be 
enough, so later on I proposed to adjust MOLD/ALL to always use 17 
digits to make sure all MOLD/ALL results will be "accurate enough".

Cyphre, how much work would it take to get https in ?  I see that 
you have tls now

would 17 digits be a minimum which we can extend using SYSTEM/OPTIONS/DECIMAL-DIGITS 
 ?

Graham, you can use HTTPS now. We don't support all cipher algos 
yet but it should work with most HTTPS connections.


We are currently looking into geting more cipher algos implemented. 
Than all HTTPS things should work.

Interesting .. didn't obviously realise that.

Are the proper source files available?

I can probe system/schemes/tls and /https

Graham, the TLS protocol scheme works transparently on tcp ports. 
So you just need to change the port/scheme from 'tcp to 'tls and 
you have the tcp connection secured. Then you can build any higher-level 
protocol over it. Having made the TLS scheme transparent I needed 
to make only few minor changes to the Gabriele's HTTP scheme to be 
able support HTTPS as well.

How did you manage this?

And are you going to implement SHA256 ?

I simply wrote the TLS scheme :-) I've also added the neccessary 
crypto algorithms at the native level (only RSA with ARC4 cipher 
suite is supported at the moment).

IMO this solution gives us much better flexibility: the encryption 
code is native(fast) and the TLS protocol logic is in REBOL so it 
is possibel to enhance it much more easily.

(so for example we can later implement also the certificate handling 
and TLS server mode)

Sure.  not needing large libraries is a plus

SHA256: yes I'd love to add it. The only problem is to get efficient 
free C implementation.

this applies also for other algorithms so any good links are welcome

so has to be compatible license and in plain C ?

I thought I found some before

I have AES algo prepared for integration. Currently we are looking 
for good implementations of: SHA256, DH and 3DES

(I guess these pieces are missing to cover TLS 1.0 cipher suite set)

Which copyrights are incompatible?

GPL

MIT or Apache

or compatible to these.

I thin BSD can fit too.

Once we manage to integrate the algorithms in form of natives it's 
just matter of adding the other cipher suites handling into the current 
TLS scheme.

compatible are GPL, MIT and Apache?

GPL? really?

that's what I was asking .. robert seems to say yes

I prefer BSD or public domain or suctom 'free' licenses as there 
I'm sure noone will complain I've stolen the code. In other lic cases 
I have no experience.

If GLP is acceptable then things would be easier. (I've seen some 
nice GPL implementations) But I'm not sure GPL code can be used for 
encapping?? But as I said I'm usually lost in the licensing stuff 
;)

I'd think GPL is out

Even Apple has a sha256 open source version out there

BTW getting the TLS/HTTPS to run on Android proves that our solution 
is good and can be easily used in crossplatform way. No need for 
any OpenSSL-like bloat anymore in R3 ;)

I haven't searched for SHA256 yet so that is possible. I'm now looking 
more for the DH and 3DES...

GPL not

One more note: AFAIK the current version of TLS + the encryption 
support increased the binary only by ~10KB which is also cool. I 
have no clue how much could take adding the rest of missing algorithms 
though.

http://www.codeguru.com/cpp/misc/misc/cryptoapi/article.php/c8195/Portable-Cryptography-API-for-Triple-DES.htm

C and C++ implementations

thanks, have that one in the candidates list as well

The time protocol mentioned in Vanity seems to need a change in design. 
There should never be a need for READ to have an /args option - that 
is what the path and query stuff are for.

Instead of this:
    read/args time://time.nist.gov [ GMT ]
it should be this:
    read time://time.nist.gov/gmt

`There should never be a need for READ to have an /args option - 
that is what the path and query stuff are for`


That's obviously problematic for systems which already make use of 
URLs including path and query components.

Are you talking about HTTP, the only scheme that has query and paths 
built into the URL spec standard? Because we have WRITE for that 
situation. For other schemes, we can define our own meaning of the 
query (and in some cases path) so we don't break the model.

read time://time.nist.gov/gmt implies to me that there is such a 
url when there isn't

or that they have such a REST service when they don't

write http://www.rebol.com[ HEAD ] is not a write but a read

Actually, it's sending a message to that server to which it is replying, 
but let's not quibble. We have other functions to get the head if 
you prefer.