Slashdot Mirror

Gray area?

$ whois legend.co.uk

Domain Name:
legend.co.uk

Registrant:
The Legend Internet

Registrant's Agent:
Legend Internet LTD [Tag = LEGEND]
URL: http://www.legend.co.uk

Relevant Dates:
Last updated: 06-Feb-2002

Name servers listed in order:
ns1.legend.net.uk 212.69.226.1
ns2.legend.net.uk 212.187.157.218

WHOIS database last updated at 13:25:01 12-Sep-2003

Nominet, the registrar for all UK domains, has elected not to include any contact information addresses, phone number and e-mail) for domain-holders of .UK domains in violation of the spirit of RFC954

The HTML spec has always _REQUIRED_ the TITLE element...

from the RFC:

5.2.1. Title: TITLE

Every HTML document must contain a <TITLE> element.

The title should identify the contents of the document in a global
context. A short title, such as "Introduction" may be meaningless out
of context. A title such as "Introduction to HTML Elements" is more
appropriate.

NOTE - The length of a title is not limited; however, long titles
may be truncated in some applications. To minimize this
possibility, titles should be fewer than 64 characters.

A user agent may display the title of a document in a history list or
as a label for the window displaying the document. This differs from
headings (5.4, "Headings: H1 ... H6"), which are typically displayed
within the body text flow.

Furthermore, you aren't even using the right status code. It's 401 Unauthorized when you want to deny access, 404 means the content is missing

Yes, but...

First, the "correct" status code would be be 403 Forbidden, 401 Unauthorized is used if "the request requires user authentication" and will cause the browser to prompt the user for login information.

And for status 403, the HTTP standard (RFC 2616) says that "If the server does not wish to make this information [explaining why the request what not fulfilled] available to the client, the status code 404 (Not Found) can be used instead." The normal use for status 404 is if the server cannot find the requested resource, but according to the RFC it is also "commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable."

So, either status code 403 or 404 are correct when trying to prevent precise ("deep") links from working. I agree that 403 is preferable.

OH NOES! IE IS BREAKING THE LAW! WERE ALL GONNA DIE COZ IE IS USING ALL THE BANDWIDTH AAAARGH...

It's called T/TCP, it's in RFC 1379 and RFC 1644, and both Apache and IIS use it.

http://slashdot.org/comments.pl?sid=49813&cid=50 22 491

OH NOES! IE IS BREAKING THE LAW! WERE ALL GONNA DIE COZ IE IS USING ALL THE BANDWIDTH AAAARGH...

It's called T/TCP, it's in RFC 1379 and RFC 1644, and both Apache and IIS use it.

http://slashdot.org/comments.pl?sid=49813&cid=50 22 491

You're citing an out-of-date RFC. 821 was superseded by RFC 2821, which makes it clear that 554 is a valid connection-opening response...

You make an excellent point. Unfortunately, RFC 821 is not yet officially superceded by 2821, as of 8/25/03 (see Official Internet Protocol Standards - note that 821 is listed as STD #10, and 2821 is listed in the table labeled "Draft Standards"). RFC 2821 compliance is still uneven among the various MTAs.

If AOL wanted to lower their load, then they should happily HELO the competi^H^H^H^H^H blacklisted cable modem ranges, and then reject the RCPT command with a hearty 550, which is not only 821-compliant but almost every mailer on earth will recognize as a permanent refusal. The mail bounces, the bounce makes it clear AOL did it, no timeout is incurred and no retries waste client or server cycles.

For AOL, it isn't about lowering their load or doing the right thing. It's about screwing their competitors, and (more importantly to me), their competitors' customers.

RFC1459 is still being heavily implemented; it is open source, secure, in current use, and fits the online dialogue needs of millions every day.

Requiring a physical medium for electricity to travel on is also prone to failures along the medium. Take the oft discussed recent blackout for example, which for all you know was a result of overloaded circuits....circuits comprised of physical conductors.

Consider wireless electricity, assuming it's a feasible idea: This article seems to think it is. I also recall an earlier /. article about it. Wireless electricity would not only help remove ugly transmission wires, and make it easy to deliver, but may also boost reliability.

And then ofcourse, there's the Electricity over IP RFC which could be adapted to wireless networks.

Well, why not use wireless electicity distribution? There even is a RFC for it: 3252 :)

I always name my files with the prefix 'NotPirated_' so everyone knows. It's the file-system equivalent of setting the Evil bit off. So now I just have
NotPirated_MetallicaEnterSandman.mp3
NotPir ated_SpaceQuestV.zip

I suggest you all do the same.

The latest revision of the SMTP protocol (rfc2821.txt) has support for IPv6.

If security is an issue, you can always use SMTP over SSL, and there is some support to allow authentication.

In a nutshell? I dont think SMTP is going anywhere in the next few years.

I beg to differ. According to RFC 1149, it's carrier pigeons. Tell the vendor that, since their product is non-RFC 1149-compliant, you're suing...

Even with IPv6, you can bet people will still be extremely stingy when it comes to handing them out

You are correct sir...only 1/8 of the IPv6 address space is going to be given out initially as unicast addresses.

About 86% of the addresses will be unassigned.

Straight from RFC3513 - IPv6 Addressing Architecture, p17

...granted, the 1/8th of the address space being given out is 4.25*10^37 addresses
...but it is still 1/8th damnit!!!!
:)

"The Metrics has you!" - J4m35 C4r73r
"What is the Metrics?" - R0n41d "The ONE" R34g4n

It will be ::1 which is short-hand for 00:00:00:00:00:00:00:1 . RFC 3513 is your friend.

Currently you can use any certificate with Secure AIM, including one from Thawte, as was pointed out by a previous poster.

Is it just me or could this have all been avoided by properly implementing the "evil bit" as mentioned in RFC3514?

It's called RTP (Real Time Protocol) which contains timestamps for determining when each packet is supposed to arrive. Feedback is sent back to the transmitters by a related protocol called RTCP (Real Time Control Protocol) which let's the sender know about "jitter" (variation in packet arrival times), lost packets, and other problems. Read RFC 1889 for more info. (RFCs available here.)

It's called congestion collapse and the condition is described by RFC 896 by John Nagle.

Just firing packets into the network willy-nilly is very bad; it's the "tragedy of the commons" all over again...

My wife viewed this and asked why in the world someone would make that. I had to explain that we geeks get a kick out of doing stuff like this, just for the sake of doing it.

I'm afraid I agree with your wife. I don't see the point of doing this either.

I mean, if you could figure out a way to send TCP/IP packets using this device, you could write up an RFC and do something really cool. (Like TCP/IP via pigeon, which is very popular with the ladies.) But I don't see how you could possibly assemble and transmit a data packet with this device. It looks like all it does is keep beer cold.

It was covered a couple of months ago here. Also, see the relevant RFC.

No need. E.164 number and DNS

RFC 3261 Section 21.4.5 clearly states:

21.4.5 404 Not Found

The server has definitive information that the user does not exist at
the domain specified in the Request-URI. This status is also
returned if the domain in the Request-URI does not match any of the
domains handled by the recipient of the request.

• Load on mail servers should go down, as it is less overhead to look up if sender S is on recipient R's white list already than it is to run 75 content filter algorithms and compute the score, etc. And you can do it before you actually accept the body of the email.
• Your second point and your third point don't play together well -- if they're all different, it makes it much harder for spammers to reply to them.
• If spammers figure out how to reply to them, they at least have to start using reply addresses that work to the first order; a first step to other forms of remediation.

• When you make your first order with the company they send you your email confirmation, and they have to have a person reply to the responder that first time. From then on they can email you. A person is generally involved with the order anyway, so it isn't that much overhead.
• You make a whitelist reply have headers like any other delivery error report. People have been sending bounce e-mails for decades, and RFCs describe how to avoid bounce-bounces.

The thing to do is bring up issues in designs like this that might be a problem, and try to solve them; not to say "It's a bad idea because I can think of 20 potential problems".

This makes sense for a few reasons.
(1) If the Matrix producers had been stupid enough to have published a real address, that site would be copping a distributed "slashdot nmapping" right now. I was at a security conference where George Kurtz (Foundstone) was giving a presentation and kept using "target.com" to describe the host getting attacked. After the presentation, a representative from Target (the chainstore) came up and told him to knock it off and start using example.[org|net|com] in his presentations. RFC2606
was written to promote example.org for exactly that purpose.
(2)Some of the previously reserved real internet address space (I forget which exactly) has now become "unreserved". But the unlucky who have been allocated this space have big problems because many old/unmaintained firewalls explicitly disallow traffic to/from those networks. So it's conceivable that the 10.x.x.x address space was opened up in Neo's time.
(3) Even without the two above scenarios, Trinity could easily already have compromised a gateway router/packet filter to an internal network. Maybe we didn't see that bit.

Why do the RFC page headers say "OGG" instead of "Ogg"? The headers in other RFCs aren't arbitrarily capitalized. It's hard enough convincing people that Ogg isn't an acronym without the RFC itself making our work harder.

Can they fix this without issuing a new RFC number?

To quote the RFC FAQ:

4) How can I correct an error in a published RFC?
You cannot! Once an RFC is published, it cannot be changed.
[...]
For both technical and editorial errors, the RFC Editor provides a list of errata for published RFCs. This page contains a list of errors that have been reported to the RFC Editor.

Why do the RFC page headers say "OGG" instead of "Ogg"? The headers in other RFCs aren't arbitrarily capitalized. It's hard enough convincing people that Ogg isn't an acronym without the RFC itself making our work harder.

Can they fix this without issuing a new RFC number?

To quote the RFC FAQ:

4) How can I correct an error in a published RFC?
You cannot! Once an RFC is published, it cannot be changed.
[...]
For both technical and editorial errors, the RFC Editor provides a list of errata for published RFCs. This page contains a list of errors that have been reported to the RFC Editor.

When the RFCs were first produced, they had an almost 19th century
character to them - letters exchanged in public debating the merits
of various design choices for protocols in the ARPANET. As email and
bulletin boards emerged from the fertile fabric of the network, the
far-flung participants in this historic dialog began to make
increasing use of the online medium to carry out the discussion -
reducing the need for documenting the debate in the RFCs and, in some
respects, leaving historians somewhat impoverished in the process.
RFCs slowly became conclusions rather than debates.

I am suprised that no one has suggested openGFS with iSCSI. This setup looks right and doesn't require any special hardware.
opengfs with iSCSI
iSCSI is a new IETF standard (RFC 3347)
that looks very prommising.

Fyodor, how long did it take you to enhance nmap to support the new IPv4 security bit (RFC) introduced just over a month ago? Or will security tools such as nmap become unnecessary once this new bit has been universally adopted?

For example, you could use the Evil Bit in TCP/IP packet headers. Non-evil, non-malicious programs should ignore any traffic marked with the evil bit. This protects those devices. If the RIAA is circumventing this protection bit (by ignoring it), you can slap them with a DMCA lawsuit.

It's an Internet Draft, not an RFC. From RFC 2026 (slightly reformatted to placate the "lameness filter"):

An Internet-Draft is NOT a means of "publishing" a specification;
specifications are published through the RFC mechanism described in
the previous section. Internet-Drafts have no formal status, and are
subject to change or removal at any time.

**
*Under no circumstances should an Internet-Draft
*be referenced by any paper, report, or Request-
*for-Proposal, nor should a vendor claim compliance
*with an Internet-Draft.
**

Note: It is acceptable to reference a standards-track specification
that may reasonably be expected to be published as an RFC using the
phrase "Work in Progress" without referencing an Internet-Draft.
This may also be done in a standards track document itself as long
as the specification in which the reference is made would stand as a
complete and understandable document with or without the reference to
the "Work in Progress".

Not quite all. See, for example, RFC-3251.

Automatically ask the Internet? I like that. Forget going to a vendor website or even Google. Just send a broadcast packet to all hosts with my query and the Internet will tell me!

I better check the Evil Bit on the reply packets if I ask for critical updates, so I know whether to trust them.

look - the only way i'm going to buy any new electronic equiptment, particularly stuff that relies on the inherently insecure TCP protocol is if it implements some of the new TCP security features.

Specifically, does anyone know if this supports RFC 3514 ?

thanks in advance.

Last winter I mulled the idea over in my head of making a voip phone with 16 bit 802.11b cards (compactflash or pcmcia). It would take a relatively low power microcontroller to encode the communications.

Slashdot, a geek news site, is running a story about a new bit in the IPv4 header (see RFC 3514) to track the security of a packet.

read here.

i'm just happy that Apple implemented RFC 3514

its very important, and i dont understand why slashdot isnt posting it.

This would be hard news to take on its own, but at the same time that BSD is dying and Apple is going out of business?! (Well, at least RFC 3514 will clear up a lot of security concerns, assuming anyone's still around to implement it.)

Mirosoft will not support RFC 3514, as it does not align with our security directions. We currently use certificates to identify trusted hosts. This proposal would mean millions of Windows users and the Microsoft domain would effectively be denied internet access. This is just another attempt by SUN and the government of China to prevent customers from using our software. We believe that everyone should just get a MS Passport account and let us identify those that are a security risk. We expect to announce a deal with a major airline carrier shortly that will provide a 5% discount to passengers that are cleared for boarding through the Microsoft Passport system. Such measures cannot be even imagined under RFC-3514. Although too advanced for Windows XP and earlier operating systems. Windows 2003 will have support for the first phase of this comprehensive security initiative. Microsoft will be expanding and offering these security services to Corporations as well as Individuals as .NET-BACK services. I think this provides another compelling reason not to install Linux or any Open Source software. It is not enough to trust the 'bit', you have to trust the bit man.

There have been varying reports, some good, some not quite as impressive, although still +1, Informative. For your reading pleasure, I've put together some of the most promising ones:
here,
here,
here,
not here,
and here.

Also, you can read the RFC in various places, including:
here,
here,
or here.

There have been varying reports, some good, some not quite as impressive, although still +1, Informative. For your reading pleasure, I've put together some of the most promising ones:
here,
here,
here,
not here,
and here.

Also, you can read the RFC in various places, including:
here,
here,
or here.

There have been varying reports, some good, some not quite as impressive, although still +1, Informative. For your reading pleasure, I've put together some of the most promising ones:
here,
here,
here,
not here,
and here.

Also, you can read the RFC in various places, including:
here,
here,
or here.

Yet it was obvious from the description:

The bit field is laid out as follows:

0
+-+
|E|
+-+

Currently-assigned values are defined as follows:

0x0 (snip)
0x1

The press release is pretty clear: "For years, in the interest of the overall health of the computer industry, we permitted the free and unfettered use of our proprietary numeric systems. However, changing marketplace conditions and the increasingly predatory practices of certain competitors now leave us with no choice but to seek compensation for the use of our numerals."

More terrifying are the implications, if you keep reading: "Because all integers and natural numbers derive from one and zero, Microsoft may, by extension, lay claim to ownership of all mathematics and logic systems, including Euclidean geometry, pulleys and levers, gravity, and the basic Newtonian principles of motion, as well as the concepts of existence and nonexistence," Yale University theoretical mathematics professor J. Edmund Lattimore said. "In other words, pretty much everything."

After all, these guys invented the Internet, right ?

Yeah, sounds like they're sending out packages with the evil bit switched on. Check RFC 3514 for more info.

And the superior one no doubt implemented RFC 3514

This can only be a good thing, for keeping the inferior BSD in compliance with the newest standards...

its really important, and i dont understand why slashdot isnt posting it.

read the whitepaper here

i'm going to kee this up until slashdot posts about the evil bit.

Never met that kid at my high school.

Oh, and did you hear about the new RFC for new security measures in IPv4?

That's 'cause the RFC number doesn't follow it's own standard. It should be RFC MMDLI (who can figure out what 2551 means? You need some sort of Greek math or something).