Slashdot Mirror

to determine if you're using a VPN client, you can always implement something like this.

Hey, is HTTP based, so how would they tell the difenrence ?

It's also has more than just a web interface. See the DICT RFC. There are clients available etc.

There's a lot more to the army now than just shooting things up. Peacekeeping missions involve communications, logistics,etc. See here for a sample script (peace-keeping in the Balkans) that they used.

The annoucement at http://www.isi.edu/uarc.html lists a couple dozen news sites that have covered this announcement.

If you're interested in the AI type stuff behind virtual/synthetic elements that would go along with this sort of thing, check out some SOAR/ASTT documents.

The annoucement at http://www.isi.edu/uarc.html lists a couple dozen news sites that have covered this announcement.

If you're interested in the AI type stuff behind virtual/synthetic elements that would go along with this sort of thing, check out some SOAR/ASTT documents.

... for the SOAP protocol is that Microsoft's ActiveX services use a portmapper to get dynamic port numbers for their services. Needless to say, this is absolute hell to try to run through a firewall with anything resembling security.

Hence SOAP. You piggyback your ActiveX control onto another service (HTTP) that uses a single port. Smart admins will use something other than port 80; we know how many of *those* there are.

There is also the problem that firewall admins tend to take their job seriously -- they know that if anything nasty gets into the network, they'll get blamed for it. They tend to be *very* conservitave. Web admins don't -- most of them think that the worst that can happen if they get hacked is that they'll get pitchers of nekkid wimmen on the corporate homepage. They don't care. *Much* easier to deal with web admins than firewall admins. Lotsa places will even let you have your own web server if you promise to be nice.

As to what it can lead to, check out RFC 3093, Firewall Enhancement Protocol (FEP)

The real problem is that most of the root servers are still maintained by the ad-hoc volunteer network of the 1980s Internet. As a result many of the 'root servers' are hosted on drinking straws rather than pipes.

Bullshit. See RFC 2870.

DNS does not provide authentication. [...] ICANN should be [...] telling the IETF the characteristics of the security protocol it really needs.

They are. It's called DNSSEC, and there's tremendous work and buzz going on about it throughout the IETF.

RFC is here

coffee.el allows Emacs users to submit a BREW request to an RFC2324-compliant coffee device (Hyper Text Coffee Pot Control Protocol, or HTCPCP). It prompts the user for the different additives, then issues a HTCPCP BREW request to the coffee device.

Exactly.

Check this link for information on test in Europe of the RFC 1149, also known as A Standard for the Transmission of IP Datagrams on Avian Carriers.

As you can see, Europe does use Pigeons!

All the best,
OpKool

Is there some confusion, perhaps on my part, between client and server here? Your previous comment said, "Return-Receipt-To is a standard, so lack of support for it is a problem of non-standard compliant e-mail client." I assumed you were saying that return receipt was a function of the client rather than the server.

Reading over the SMTP specs there seems to be more handshaking than I thought. Certainly, servers are prompt in sending "mailbox not found" messages back to the sender.

I was under the impression that mail could be delayed at some point in the relay chain without the sender being aware of it or being notified of it until much later. If I'm wrong, I appreciate you taking the time to make it clear.

There should be a way of returning undeserved karma points in such cases.

E-mail, arguably the most successful of all computer applications, has grown so rapidly that it' threatens to veer out-of-control for many people.

Huh? Can you give us one example of Email veering out of control and hitting someone? Or even just veering out of control? How, exactly, would that work?

Designed as a simple communications tool

A simple communications tool? Jon wouldn't have taken offense, he wasn't like that, but he should have.

it's now used for dozens of tasks, from personal archiving to community-building and marketing.

And spam and commercial harassment. Don't forget to list the most frequent uses first.

E-mail is sparking, perhaps even overwhelming, the revolutionary new model of instantaneous communications.

E-mail is overwhelming Aol Instant Messenger?

This is the first time in human history disparate people in diverse places can communicate with one another instantaneously.

...using letters, instead of the crude voice signals they had to use eighy years ago.

I take it back, this article just veered out of control. It ran me over.

No need to get all hyper by thinking about spooks following you around.
For those who actually read the article, it mentions the ENUM adresses are based on a variant of the DNS system where the adress ends in x.e164.arpa. Cute... and the IETF has something to do with that.

E.164 sound a bit like V.90 doesn't it? Thats because they were named by the same body, the ITU.

If you don't trust the US Gov, will you at least surf over to the IETF or the ITU's website and get the specs and make your own opinion?

Microsoft often abuses popular names and words that have some established meanings in some nearby area to confuse the heck out of users -- bright example of that is "Digital Nervous System" that seems to "share" an acronym with Domain Name System that happens to predate Microsoft's definition by a decade, and, while mentioned a lot, probably isn't clearly to its target audience.

Now where have I seen the word "Merlin" very close to PDAs, but not exactly a PDA-related item last time? Wasn't it a PC version of a popular Minstrel PDA CDPD modem, made by Novatel? Indeed, it is! And, just like with "DNS" and other cases, I don't think that it's a coincidence -- it may not be illegal, but it's hijacking someone else's trademark with the goal to make users think that Microsoft's product is related to something they have heard about.

I'm possitively stunned at the near sighted responses to the minimal effect, if any, that could be attributed to giving the "at home user" access to raw sockets.

MacOS (about as "home user" as you can get) has had access to raw sockets for years - where is the war cry there? Should Steve Gibson want to rally a war cry (or rant) about WindowsXP's security, or lack thereof, let him... assuming he's found some bugs to bitch about. But here sits a man spouting FEAR, UNCERTAINTY and DOUBT - about an un-released OS that gives the casual programmer more access to his networking stack.

Plain and simple... Gibson is fighting the wrong battle and he does it in a journalistic style that leaves me wishing for better material to read... hmm where is the Weekly World News?

The answer isn't taking access to core parts of the OS away from the user (or the developers that can make legitimate use of it). The answer is fixing the core problem.

ftp://ftp.isi.edu/in-notes/rfc2460.txt

RFC765 is from 1980. That's the one that 959 makes obsolete, and it's a good standard for FTP, so that makes FTP prior art by five years.

Wouldn't the concept of FTP, being designed in an RFC from 1980 be prior art?

Granted, this may not help for the sale of items over the Internet, but that DOES mean that they couldn't claim EVERY software download.

...as I understand it, ICANN was just sort of created by the Commerce Department without regards to any outside opinions.

This is untrue. There was an extended process of consultation, involving meetings in Geneva (which I attended), Singapore, and Buenos Aires.

It seems like the Commerce Department is extending governmental rights to ICANN since the Commerce Department pretty much goes along with whatever they say.

Well, and what else are they going to do? If the United States Government tried to control Internet governance, the rest of the world would not be very pleased, to put it mildly. Face it, the Internet changes things, and makes national governments less and less relevent. We have to develop new ways to govern the Internet, and ICANN is an experiment. Personally I preferred it's predecessor, and I agree that the current lawyer-driven ICANN is a bit of a mess. But we're learning.

Perhaps we, as Internet users, should petition the Commerce Department for changes we want to top-level domains and other naming issues. To this end, I think we should question the foundation of ICANN.

What has the government of one nation got to do with it? How can the United States government change things? If you want to change things, join ISOC and come to Stockholm next week. If you come to my tutorials, I'll even stand you a beer!

There is not a single point of failure. There are something like 14 root name servers, and the security of each one is taken very seriously.

immediately and globally engage in mass copying, uploading, downloading and distributing of all copyrighted and patented materials.

The saved seeds are far superior collections of genetic material, in that the patented seeds are closely bred (ie, ``thin'' genetic material, won't breed true) and/or genetically modified, so almost always require special (expensive, proprietary) fertilisers, pesticides etc ad nauseum in order to produce their huge yields.

Finally, the whole idea is an open source/sharing kind of thing, very much in tune with the current software revolution.

immediately and globally engage in mass copying, uploading, downloading and distributing of all copyrighted and patented materials.

The saved seeds are far superior collections of genetic material, in that the patented seeds are closely bred (ie, ``thin'' genetic material, won't breed true) and/or genetically modified, so almost always require special (expensive, proprietary) fertilisers, pesticides etc ad nauseum in order to produce their huge yields.

Finally, the whole idea is an open source/sharing kind of thing, very much in tune with the current software revolution.

People seem to think that "self-describing data" is going to save the world in the same way that XML was supposed to eliminate the need for parsing and interpretation of information by a computer program.

Self describing data is going to "save the world" (for small value of "save") - but XML never did that, and XML Schema barely begins to either. If you're going to communicate, then you don't just need self describing data, you need a shared vocabulary of description -- and this is a problem for DAML+OIL et al., not just XML Schema.

XML has removed the need to parse, or at least the need to write new parsers. XML Schema allows structural comprehension (which isn't the same as an ontological understanding) and validation to be similarly automated once and for all by a common toolset with a single API.

you still have to write programs to interpret the contents of the XML information in pretty much the same way as with data exchanged in any format.

You still need to "interpret", but you no longer need to parse. If your documents fit into the RSS 1.0 model, then interpretation becomes trivial for all documents expressible in RSS 1.0, because RSS 1.0 has a shared ontology behind it that's implicit in the use of the protocol. If you use RDF in conjunction with something like DAML+OIL, then you gain the same advantages, but over a much woder range of application than that of a "newsfeed"

XML alone can't remove the interpretation burden for you, but it can remove the parsing burden (which isn't trivial) and some of the protocols on top of XML, such as RDF, remove further horizontal slices of this "interpretation" workload for you.

most functioning protocols out there are able to exchange information without the need for a formal validation model

All protocols that work have a validation model -- but sometimes it's implicit and informal. You either do this (you "trust" the information provider) or you formalise it. Formalising it has two advantages; it removes some of the "trustworthiness" issues about unknown providers, but it also allows the "allocation of trust" to be deferred to individual documents. Rather than pre-agreeing with a known and trustworthy provider that they'll send you documents, they'll be valid documents, and you know the format for which they'll be valid, then you can do this for each document as it arrives. This is great, because it now means you can receive docuemnt formats you've never seen before, and you can still build a useful level of trust upon them. Implicit trust is great, but it limits you to providers you know about, and to formats that you know about.

Not that you would really want to use one [a validation schema] on either the generation or consumption side of a real system, since it just slows things down.

It doesn't slow things down, it speeds them up. Think of network protocols and the layer stack model. The lower level you can perform an operation at, then the dumber that operation becomes and the less work it is to do it.

Ignoring the trivial "I don't care if this goes wrong" applications, then all applications need to validate data that they receive from external systems. If I can validate an invoice as being structurally valid by expressing useful constraints in a low-level schema (like XML Schema, but more likely DAML), then that's a lot quicker to work on than interpreting the document to be a data structure or object state for an invoice (which may have been so broken so as to raise an exception when I unserialized it) and then validating that object's internal state. Someone needs to do this validation, and it's quicker to do it low-down and dumb (and it's no less valid or reliable to do it that way).

Another thing that bugs me is the fiercely defended text-only approach used in XML.

Text only is good. It's fundamental to XML (XML Schema cannot change this) and there are many good arguments presented from back in the SGML days onwards as to why this is the right way to do it.

First, there's no way to directly include binary data

Don't need it. Encode it instead. Yes, there's an overhead (both in processing, and in volume) but that's minor, the advantages outweigh it, and DUMB ENCODING IS WHAT COMPUTERS ARE FOR !.

There's an argument that a DOM should be binary-aware, but no reason at all that the serialized XML document should be.

This is pretty strangely limited given that XML data is generally exchanged over an 8-bit clean pipe (i.e., the Web).

The web is not 8 bit clean, and the usage of character sets mean that anything in the top bit is already exposed to mis-interpretation errors. I guess you're American, because developers in most other countries hit this problem on a regular basis.

Also, XML is 16 bit clean (sic, in some views), because it's perfectly OK to Unicode that CDATA. I really do NOT want a binary route through XML that makes my application worry about whether the XML document had passed through an 8 bit, UTF-16 or even EBCDIC (!) transport on its travels.

<xml:binary size=10>kjiu õéçäá</xml:binary>

would be quite reasonable, with "size" octets placed directly between the closing '>' of the opening tag and the opening '' of the close tag.

First of all, your XML fragment sucks; xml as a namespace local identifier already has implicit connotations - i.e. xml:lang, and you ought to be quoting attributes properly if you're trying to lecture on syntactic changes.

Secondly, what's an "octet" ? There are no octets in XML - An octet is a well understood term in low-level comms meaning, "We have no idea what a word length is on this crate, or if a char is 7, 8 or 5 bit clean, but an octet is going to have exactly 8 bits in it". In XML, you just don't know this. It's hidden from you, and it's done deliberately so that your apps don't need to worry about it. If you change this, and make it visible, then that breaks a whole lot of i18n text-processing code.

They should have included a mechanism in XML Schema to declare this.

They can't. Even if it was a good idea, that level of change would have to be in XML itself, not XML Schema.

What is needed is a simple, widely acceptable binary encoding of exactly the information included in XML text, which uses lookup tables to optimize handling tag names.

We already have this. It's Huffmann coding, and any network protocol will already be doing it for you, low-down in the stack.

The third problem with exchanging raw text XML encoded data is that it explodes the information you want to ship

See above. Bloat is bad, but it's dealt with low-down.

The MIME tags really need to be updated too

They have been. See RFC 3023.

There are a few hopeful signs on the horizon though. IPv6 should make routing a lot easier and give us a lot more operational "breathing room" which we can use for redundancy and robustness.

After pouring over things like this and this, and keeping in mind the recommendations in other RFC's and discussions, I can't find anything that supports this. We certainly get breathing room as far as more address space, but how does this lead anything but requirements for more routing complexity to keep tabs on it all?

--

There are a few hopeful signs on the horizon though. IPv6 should make routing a lot easier and give us a lot more operational "breathing room" which we can use for redundancy and robustness.

After pouring over things like this and this, and keeping in mind the recommendations in other RFC's and discussions, I can't find anything that supports this. We certainly get breathing room as far as more address space, but how does this lead anything but requirements for more routing complexity to keep tabs on it all?

--

From the article:

Gartner recommended that managers train employees to use e-mail more efficiently, including using distribution lists with caution by sending e-mail to only those who need the information or avoid sending needless responses, such as "I'm with you 100 percent" or "Glad to be of help."

Seems it's true that people often need reminding of old truths. RFC 1855, section 3.1.3, said just the same back in 1995:

• [...] Avoid posting "Me Too" messages, where content is limited to agreement with previous posts. Content of a follow-up post should exceed quoted content.
• Send mail when an answer to a question is for one person only. Remember that News has global distribution and the whole world probably is NOT interested in a personal response.

RFC1459 specifies a cross platform instant messaging protocol. Included is the ability to send/receive files, create chat groups, and "instant message" another user directly. It's really cool. Maybe these newbies should try it sometime and quit reinventing the wheel. What's next on your drawing board? A platform independent way of sending text and graphics over a packet switched network where users click on "links" to go to other "pages"? ;-)

Interoperability and a clear migration path are part of IPv6 ( Transition Mechanisms for IPv6 Hosts and Routers, Routing Aspects Of IPv6 Transition and Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels ). As a home user you can easily join the 6bone and be part of the magic. So, anyone who wants to switch to IPv6 can do so without a lot of trouble. For more info and the site where I stole those links from check out: IPv6 site

Interoperability and a clear migration path are part of IPv6 ( Transition Mechanisms for IPv6 Hosts and Routers, Routing Aspects Of IPv6 Transition and Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels ). As a home user you can easily join the 6bone and be part of the magic. So, anyone who wants to switch to IPv6 can do so without a lot of trouble. For more info and the site where I stole those links from check out: IPv6 site

Here are some stats from ARIN (unfortunatelly these are circa 1996...):

Grand Total (Allocated and Assigned Combined)
Class A - 127
Class B - 10150
Class C - 764202

Right... so there are 127 institutions with class A's all to themselves. Now that's really efficient. Even a full class B (which 10000 organizations have been blessed with) is overkill.

Percentage Allocated (Allocated and Assigned Combined)
Class A - 100.00%
Class B - 61.95%
Class C - 36.44%

Now, the offenders are here (this list _is_ up-to-date). Most notable class A assignments:

• GE (ok - 1)
• Bolt Beranek and Newman (BBN? that's a lot og IPs - 3)
• IBM (ok - 1)
• ATT (hmm, I guess telcos need some IPs too - 1)
• Xerox (well earned - 1)
• HP (lotsa research, ok - 1)
• DEC (same, ok - 1)
• Apple (definitely overkill - 1)
• MIT (well earned as well - 1)
• Ford (good one! - 1)
• Halliburton Company (huh? - 1)
• PSI (hehe - 1)
• Eli Lily and Company (wtf? who are these guys? - 1)
• Bell-Northern (no comment - 1)
• Prudential Securities (that's funny... - 1)
• duPont (I'm sure they're using it all... - 1)

The rest goes to IP registries to dish out in comparatively puny class B and C chunks, and of course the US government.

...humans will never give software enough scope to achieve consciousness and real life...

Better yet! We can now implement RFC2795 (the Infinite Monkey Protocol Suite) in Perl! Who wants to start a page on sourceforge? :)

Shayne

It's nice to see that the folks at this Open Source Directory are modeling the software categories after Sourceforge'.s Software/application taxonomies typically vary from site-to-site and distribution-to-distribution. While I appreciate that all the site maintainers out there take time to organize information about software applications, the diversity makes it difficult to synthesize materials from multiple sources. I applaud this directory's deference to a previously-existing taxonomy.

A while back, I started creating a list of software categorization schemes/systems relevent to Linuxland:

http://freshmeat.net/browse/627/
http://apps.kde.com/na/2/categories&nav=f
http://sourceforge.net/softwaremap/trove_list.php
http://dmoz.org/Computers/Software/
http://dir.yahoo.com/Computers_and_Internet/Softwa re/
http://ftp.us.debian.org/debian/dists/potato/main/ binary-i386/
ftp://ftp.ibiblio.org/pub/Linux/
http://www.gnu.org/gnulist/production/index.html
http://www.userfriendly.net/linux/RPM/Groups.html
http://www.cpan.org/modules/by-category/
http://www.freebsd.org/ports/
ftp://ftp.isi.edu/in-notes/iana/assignments/media- types/media-types
http://www.pathname.com/fhs/
http://www.labs.redhat.com/gug/users-guide/main-me nu.html
http://www.linux.com/links/Software/

I know almost nobody will read this, but don't miss the other RFCs released on April 1st, 2001. True gems like the Pi Digit Generation protocol, that states "One REQUIRED PIgen service is defined as a stateless TCP service. A server listens on TCP port 314159.".

And also, don't miss this very interesting RFC called the Etimology of foo, with more than useful information about the foobar!

At least, these are _technical_ April Fools jokes :-)


You're tired of Slashdot ads? Get junkbuster now!

I know almost nobody will read this, but don't miss the other RFCs released on April 1st, 2001. True gems like the Pi Digit Generation protocol, that states "One REQUIRED PIgen service is defined as a stateless TCP service. A server listens on TCP port 314159.".

And also, don't miss this very interesting RFC called the Etimology of foo, with more than useful information about the foobar!

At least, these are _technical_ April Fools jokes :-)


You're tired of Slashdot ads? Get junkbuster now!

The AF on avian carriers beats this hands down.

Not to mention the follow-up RFC update with QoS

The AF on avian carriers beats this hands down.

Not to mention the follow-up RFC update with QoS

With the Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)

Unfortunatly the way we're going now the protocol may actualy become useful one day....

Imagine, BeCoffee, All your coffee needs catered for using fully RFC compliant software, order your coffee anytime any where from over the internet. Never have to wait for instant coffee again !

RFCs 3091 (Pi Digit Generation Protocol) and 3092 (Etymology of "Foo") are also available. Looking over the comments here, they're probably funnier, too.

RFCs 3091 (Pi Digit Generation Protocol) and 3092 (Etymology of "Foo") are also available. Looking over the comments here, they're probably funnier, too.

There are a lot of groups working on similar stuff:

http://www.ccm.ece.vt.edu/acs_api - This is my group and I apologize for the lame web page. http://splish.ee.byu.edu These guys do very good work, especially when it comes to hardware description languages. http://www.east.isi.edu/projects/SLAAC/ We like these people too. http://www.annapmicro.com A lot of our graduates go here.

There are several more groups - you can find a more complete list on the People section of ISI's web site.

This is bad for two reasons:

I disagree about as strongly as it's possible to disagree. Content negotiation is a Good Thing(tm).

Here's an example: when I go to a web site, I expect (hope?) that the content of the site will be rendered in English. For large web sites with a multi-lingual user base, that's not always a safe assumption. Fortunately, content negotiation makes that possible.

3.10 Language Tags
A language tag identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to other human beings. Computer languages are explicitly excluded. HTTP uses language tags within the Accept-Language and Content-Language fields.
- from RFC 2616

Apache makes on-the-fly decisions about what content to send based on this.

Does that mean that webmasters need to be careful about how they set up their sites if they're using this technique? Sure. But it also opens up a wide range of options.

1. It's more expensive to design 2 sets of pages. That money should be spent on more content.

Speaking on behalf of webmasters everywhere: thanks for telling me how to spend my money. Allow me to suggest that doing two versions of the same image - one at a high bit-depth, and another at a lower quality - isn't too much of a strain on my budget.

2. Sometimes people with slow modems don't mind waiting - maybe they let your site load in the background while they do something else. It's not polite to make these choices for your users.

Content negotiation doesn't have to be like making the choice for the user. Instead, it can work as a reasonable best-guess. Besides which, I've seen plenty of sites which simply assume high bandwidth (or pathetic bandwidth) and make all the design decisions based on that information. In what way is that giving the user a choice, other than to vote with his feet?

-----
"You owe me a case of beer. Sucka'."

It's an HTTP header. Check the HTTP 1.1 RFC, around page 116. HTTP is a generic application-level protocol that is frequently used to transfer text/html files, but also Content-types of image/jpeg and other useful data formats.

This could be really useful for implementing a local-area complement to the wide-area datagram transmission protocols described in RFC1149 and RFC2549.

Avian carriers are perfect for transmitting datagrams between different locations and model train networks could be leveraged to deliver the datagrams within the office/building...

D.

This could be really useful for implementing a local-area complement to the wide-area datagram transmission protocols described in RFC1149 and RFC2549.

Avian carriers are perfect for transmitting datagrams between different locations and model train networks could be leveraged to deliver the datagrams within the office/building...

D.

Surely using the format described in RFC2550 would be a more sensible way to represent the date? Particularly if they keep delaying it. :-)

I can't agree with that. while the Campanile film is stunning, it seems to require a handcrafted 3d model onto which to wrap the multiple images.

Actually, if you read his thesis, you'll discover that a large proportion of the modelling process was done by the computer. A number of photographs from different angles were used as the source, and lines traced on them by a human operator. The actual three-dimensional structure and proportions were then determined from those by the computer, and relevant, direction-dependent textures recovered and applied.

Pretty interesting reading - a very different procedure to that described in the posted article, but who cares. :-)

Ford Prefect

I visited NATPE and talked to some people about HDTV and it looks like its starting to happen. Some channels are already broadcasting in japan.

But even though the HDTV consortium contains 19 formats it looks like there is an emerging universal mastering format 1080/24P 1980*1080 pixels 12 bits per channel (48 bits per pixel) 24 frames per second. (you can most likely find this resolution in your display settings). The bandwidth needed for this format is about 220 megs per second. we would need a fire wire cable capable of more then 1760 Mbit to be able to hare real-time transfer (the current fire wire is capable of 400 Mbits). The point is that HDTV is not that far away. I mean this is uncompressed!

My computer is ready for it, and so is my display, but so far there are no consumer cams out there and renting a sony HDTV cam will cost you about 1700$ a day! even though many digital still cams can take substantially higher resolution images (i guess its the bandwidth....) it is going to be interesting to see who will be first whit a consumer HDTV cam... sony? canon?

But the thing that i am waiting the most for is 12bits per pixel, its not HDRI (High Dynamic Range Images) but its a lot better then 8 bits.

Now let me rant a bit about resolution :
It has taken about 15 years to get to this point (this tells you a bit about how serious tv people are about formats). And the really silly part is that a mpeg image does not have a set resolution. the resolution is just a part of the header as a "please un compress this data to this resolution" statement. So since all DTV(digital tv) will be mpeg there is no need for a fix resolution. you could in fact just broadcast the data an let the receiving tv set, unpack in in any resolution! This would also make it possible for different programs to be broadcaster in different aspects. every one seams happy whit the fact that "wide screen" is 16:9, but nothing is filmed in 16:9, most films are made in 1.85:1, 2:1, 2.1:1 or even 2.34:1 so we will still get borders on our tv sets, borders that will be broadcasted and take up bandwidth! why cant i buy a TV set whit the aspect and resolution i want and then just de-code the tv signal the way I want?

Eskil

You might have seen it already, but a forerunner of this technique more suited to getting a 3D model of architecture is described at Paul Debevec's Home Page, with the famous Campanile film. It's pretty amazing what can be done - perhaps one day digitised actors can stroll around a digitised building, with various other additions made to it...

Ford Prefect

Actually, to roll your own without exposing yourself to side attacks is really difficult.

Not really. Take a look at the RFC2040 description of the RC5 algorithm. It includes C reference implementations for just about every part of RC5, so that a programer would just have to stitch them together to create a useful program. Nor is this a singular example; IIRC part of the requirement for the new advanced encryption algorithm developed by the US was that there be a published, freely available reference implementation. I didn't bother to look, but I'll bet that there's similarly available information about well established asymmetric cyphers like RSA. This stuff is published and can't be unpublished.

If you telnet into your friendly, neighbourhood POP2 server you can use commands found here which are explained in excruciating detail in RFC1939. Who needs a mail client.:)

IMHO, as per
J:)