Slashdot Mirror

• Released October 27, 2005 changelog

• Numa-aware slab allocator: It creates slabs on multiple nodes and manages slabs in such a way that locality of allocations is optimized. Each node has its own list of partial, free and full slabs. All object allocations for a node occur from node specific slab lists (commit - benchmarks)

• Lazy page table copies in fork() for VMAs without anonymous pages (the ones with anonymous pages are still copied): Defer copying of ptes until fault time when it is possible to reconstruct the pte from backing store, speeding up fork() greatly specially for processes using lots of shared memory (commit)

• Add /proc/$PID/smaps: This file will shows how much memory is resident in each mapping. Useful for people who want to perform memory consumption analysis (commit)

• Add /proc/$PID/numa_maps: This file will show on which nodes pages reside (commit)

• Lock-free file descriptor look-up (commit) - (commit)

• Four-level page table support for the ppc64 architecture: extends the usable user address range to 44 bits (16T). (commit)

• Support hotplug cpu on 32-bit SMP powermacs: When a cpu is off-lined, it is put into sleep mode with interrupts disabled. It can be on-lined again by asserting its soft-reset pin, which is connected to a GPIO pin (commit)

• Add TASK_NONINTERACTIVE task state bit to the cpu scheduler: It can be used by blocking points to mark the task's wait as "non-interactive". This does not mean the task will be considered a CPU-hog - the wait will simply not have an effect on the waiting task's priority - positive or negative alike (commit)

• PPTP (Point-to-Point Tunneling Protocol) support: RFC 2637. Used to implement VPN products (notably, Microsoft in all the Windows versions). Wikipedia article (commit)

• DCCP: "Datagram Congestion Control Protocol". Datagram protocol (like UDP), but with a congestion control mechanism. (LWN article) Currently a RFC draft (commit)

• Implement SKB fast cloning: Protocols that make extensive use of SKB cloning, for example TCP, eat at least 2 allocations per packet sent as a result. To

Real-time Transport Protocol (RTP) was accepted as an IETF standards track protocol in January 1996. The research goes back as far as the 1970's.

that is essentially TCP

RTP is not specific to any particular transport layer, but in IP networks is layered upon UDP.

That being said, it most assuredly cannot be used over TCP.

Furthermore, it is most unlike TCP in that it is an unreliable transport protocol.

augmented by a "QOS" (guaranteed minimal throughput) feature.

From the RFC:

Note that RTP itself does not provide any mechanism to ensure timely delivery or provide other quality-of-service guarantees, but relies on lower-layer services to do so. It does not guarantee delivery or prevent out-of-order delivery, nor does it assume that the underlying network is reliable and delivers packets in sequence. The sequence numbers included in RTP allow the receiver to reconstruct the sender's packet sequence, but sequence numbers might also be used to determine the proper location of a packet, for example in video decoding, without necessarily decoding packets in sequence.

Real-time Transport Protocol (RTP) was accepted as an IETF standards track protocol in January 1996. The research goes back as far as the 1970's.

that is essentially TCP

RTP is not specific to any particular transport layer, but in IP networks is layered upon UDP.

That being said, it most assuredly cannot be used over TCP.

Furthermore, it is most unlike TCP in that it is an unreliable transport protocol.

augmented by a "QOS" (guaranteed minimal throughput) feature.

From the RFC:

Note that RTP itself does not provide any mechanism to ensure timely delivery or provide other quality-of-service guarantees, but relies on lower-layer services to do so. It does not guarantee delivery or prevent out-of-order delivery, nor does it assume that the underlying network is reliable and delivers packets in sequence. The sequence numbers included in RTP allow the receiver to reconstruct the sender's packet sequence, but sequence numbers might also be used to determine the proper location of a packet, for example in video decoding, without necessarily decoding packets in sequence.

Which sounds to me like it would cover transferring XML with a schema embedded within the document, or transferring both the document and linked schema at the same time. Other uses of XML would still be allowed.

The schema is encoded in the same format as the data.

Part 'c' is essentially described on page 14 of RFC 1014 (External Data Representation), June 1987. http://www.ietf.org/rfc/rfc1014.txt

This has been done. 192.88.99.1 is a magic address that should route towards the nearest 6to4 gateway.
See also: RFC3068

XMPP is based on XML messaging and is used by Jabber. Google base their service on XMPP, but have not shown any intent of interconnecting with others.

SIMPLE is derived from the dominant VOIP signalling protocol, SIP, and is used by several enterprise products of Microsoft (Life Communication Server, LCS), IBM (Lotus Same Time) and others. The enterprise servers can be interconnected much like e-mail servers, i.e. by resolving SIP URL over the DNS. Microsoft also proposes a SIMPLE based solution for connecting LCS servers to MSN, Yahoo and AOL. The interconnection between MSN and Yahoo is most likely based on SIMPLE.

I guess the first thing we need is some kind of gateway between XMPP and SIMPLE...

XMPP is based on XML messaging and is used by Jabber. Google base their service on XMPP, but have not shown any intent of interconnecting with others.

SIMPLE is derived from the dominant VOIP signalling protocol, SIP, and is used by several enterprise products of Microsoft (Life Communication Server, LCS), IBM (Lotus Same Time) and others. The enterprise servers can be interconnected much like e-mail servers, i.e. by resolving SIP URL over the DNS. Microsoft also proposes a SIMPLE based solution for connecting LCS servers to MSN, Yahoo and AOL. The interconnection between MSN and Yahoo is most likely based on SIMPLE.

I guess the first thing we need is some kind of gateway between XMPP and SIMPLE...

So basically we're going back to the days of IRC, albeit in a different front-end format.

Eh. XMPP > IRC. My understanding is that it's roughly a cross between SMTP and IRC. (I've actually written a Jabber bot, but I didn't get too far into the raw protocol.)

It does sound good, in some ways, but I worry about rogue servers and rogue clients. IM has been virtually free of direct spam attacks (I have only received one in my entire life), and I fear that without having some corporation's control in their propietary medium, we'll see more spam and less usefulness.

Rate limiting. Jabber has a "karma" mechanism, kind of like ircd's I-lines. (Is this part of the RFC?) Besides, you're invisible by default; you don't get messages unless you allow a "subscription" (read: unless you let the other guy add you to their buddy list). Clicky, clicky.

Besides, how often do you see spam on efnet?

Look what happened with the "open standard" of Usenet. It is SO informative and so readily useful, isn't it? I'm not a fan of most Yahoo Groups but the ones I read are generally spam free (moderators) instead of being spam magnets.

Eh. Usenet didn't go to hell because it was an open standard, it went to hell because it, like a lot of other protocols, was basically designed to be trusting.

I'm willing to hear reasons why Google's desire to have a open server-to-server federation will be good for a product that already offers me everything I need (at the moment).

Because if it suddenly stops offering you everything, you can write your own, or use another one that does.

If Google's "don't be evil" thing suddenly goes away, it won't affect you as much as if AOL suddenly said "be incredibly evil" and shut down AIM.

What new features are going to replace the current text-to-text feature that is probably used by 100% of IM's users.

Whatever anyone feels like implementing. Encryption, games, audio, video, tunnelling (?), whatever.

Is VoIP really an extension to IM or is it a different product?

*shrug* I guess it'd depend on how it was implemented; offhand, I'd say a little of both.

Aren't there enough programmers added on features to the propietary AIM program that is doesn't seem to warrant the need for a more open standard?

<text tone="polite"> Do you see any (official) Linux AIM clients (that aren't horribly outdated)? AIX? HP-UX? </text>

Does the propietary standard offer manufacturers more reason to police their networks of abusers,

I don't see how...

and is it wrong for these companies to assume to make a profit in order to pay for the massive infrastructure needed to provide IM services?

...I'm not sure I'm getting your point, here. The Jabber server is peer-to-peer. If you can get people to pay for it, cool.

I do understand the need to open the standard for client-server interaction. More clients means more features, more stability, and more control over your applications on your computer. It also means more clients for lesser-used operating systems, better integration into non-PC stations (media centers, phones, etc), and possibly more people using the IM system.

Exactly. This is how Jabber works; your client talks to whatever server you have an account on, and that server talks to other servers, kind of like Email. Google could use Jabber for the client-server,

...with few people even remembering that OSI was supposed to be a competitor to TCP and built along fundamentally different assumptions ...
The problem is compounded by broken requirements like knowing the OSI model which is not only dead but broken.

I'll bite.

Why does the fact TCP and OSI were once competitors matter in modern discourse? Further, what is more dead and broken about the OSI 7 layer model versus the DoD 4 layer model? Finally, how exactly are the basic assumptions of OSI and TCP so different? (The prioritization of goals may be somewhat different, interoperability versus reliability for instance, but I don't see how the basic problem spaces differ so extremely.)

I certainly hope you're not arguing against layering of protocols altogether.

The current standard says that "back" should always load from cache, but for a long time it didn't directly address it

It's been directly addressed since the first specification:

User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session. By default, the Expires field does not apply to history mechanisms. If the entity is still in storage, a history mechanism should display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents.

Opera will unconditionally load from cache. I believe that Opera will load from cache even with a page that has no-cache set, which is wrong.

Technically, "no-cache" doesn't mean "don't cache". That's what "no-store" is for. RFC 2616 says that clients must revalidate (not refetch) no-cached documents before using them for subsequent requests:

If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server.

I wouldn't consider hitting the back button to be a subsequent request, since the specification is quite clear that hitting the back button is going back in history, not showing the current state. Furthermore, even the more restrictive "no-store" is specifically allowed to be used in conjunction with history lists:

Even when this directive is associated with a response, users might explicitly store such a response outside of the caching system (e.g., with a "Save As" dialog). History buffers MAY store such responses as part of their normal operation.

Precisely what the "correct" behavior is, by which I mean "what the user expects" will vary from case to case

What's your basis for claiming that? I believe users who hit the back button want to see what they previously saw, and only a small minority (i.e. web developers) understand how things work well enough to expect anything different.

Netscape and IE both implemented what they thought was right

Do you have any evidence of this? I'm more inclined to believe they implemented what was easier.

and have retained that behavior for consistencies sake even though some of the purists in the standards bodies have changed it.

That's not true; nothing has changed since the first formal specification. No demonisation of "purists" please.

Isn't this basically just emphasing what groups have been trying to do for years?

RFC's for example:
http://www.ietf.org/rfc/rfc1730.txt being the IMAP4 Protocol.

That is of course assuming that Protocols can be defined as Standards.

Or is this just people trying get get other systems such as the MSN Protocol in the open? Rather than people trying to work it out http://www.hypothetic.org/docs/msn/index.php?

Back on track:
I always feel "cleaner" when I follow standards. Building websites with the proper usage of CSS for example.

/me carries on RTFA.

It's not just inconvenient. It's wrong in principle; 'back' should be 'back to precisely what I received previously', not 'attempt to re-get whatever now appears at the previous URL.' If I want the page refreshed, I will use the provided 'refresh' button, mkay? Thanks.

There's probably some profoundly crucial and subtle reason for all this and I've foolishly revealed my ignorance. Apply the necessary flames, but only if you have credible answers.

No, you are absolutely right. From RFC 2616 (the HTTP 1.1 specification):

History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.

I thought that just going to be RFC 1149 with robots?

the .xxx domain name is another good place to start

In principle I'd be more than happy for such a new top level domain, if it were not for:

we can then pass laws requiring such sites to be in the .xxx domain

that inevitable and disasterous demand.

Internet RFC 3675 " sex Considered Dangerous " may seem like a joke, but it isn't. It is 100% serious and it gives many critical reasons why such a law would be stupid and harmful. If you want a child-safe zone on the internet, fine, it already exists in .US.KIDS. Trying to turn the entire internet into one giant child zone is a Very Bad Idea.

There was a Slashdot story on this already.

-

Better link: RFC4010

In past, there were no 128bit browser for international users. But, 40bit is very weak for financial service. So Korea chose plugin based internet banking and made own 128bit algorithm called SEED. Firstly, both NSPlugin and ActiveX were supported. After browser war, there is no market share of Netscape. So most of banks stop NSplugin. The SEED goes to world standard. http://www.ietf.org/html.charters/smime-charter.ht ml http://www.ietf.org/internet-drafts/draft-ietf-smi me-cms-seed-02.txt

In past, there were no 128bit browser for international users. But, 40bit is very weak for financial service. So Korea chose plugin based internet banking and made own 128bit algorithm called SEED. Firstly, both NSPlugin and ActiveX were supported. After browser war, there is no market share of Netscape. So most of banks stop NSplugin. The SEED goes to world standard. http://www.ietf.org/html.charters/smime-charter.ht ml http://www.ietf.org/internet-drafts/draft-ietf-smi me-cms-seed-02.txt

Defining Ethernet and TCP/IP as layers of the OSI stack is about as correct as defining the XBox as the successor to the Playstation.

The OSI stack was a failed, over-complex set of network protocols that tried to wrest control from the established, pragmatic, but not-officially-ISO-sanctioned TCP/IP (aka DARPA) protocol suite.

The TCP/IP suite model defined four layers: Network, Internetwork, Transport, and Application. That's (for example) Ethernet, IP, TCP, and HTTP for most implementations of teh Intarweb.

The OSI _model_ (not stack) is, in fact, the seven-layer cake you mention. Over the past decade or so, networking companies have "retrofitted" the OSI model onto the de facto stack, but you'll notice that they get a little wishy-washy at Layer 1, Layer 6, and Layer 7. Guess why? Because in the OSI Stack, there were actual protocols specified for those levels.

(definitely glad I learned the networking side of CS from folks who invented it, rather than someone who learned it later, out of a book...)

Defining Ethernet and TCP/IP as layers of the OSI stack is about as correct as defining the XBox as the successor to the Playstation.

The OSI stack was a failed, over-complex set of network protocols that tried to wrest control from the established, pragmatic, but not-officially-ISO-sanctioned TCP/IP (aka DARPA) protocol suite.

The TCP/IP suite model defined four layers: Network, Internetwork, Transport, and Application. That's (for example) Ethernet, IP, TCP, and HTTP for most implementations of teh Intarweb.

The OSI _model_ (not stack) is, in fact, the seven-layer cake you mention. Over the past decade or so, networking companies have "retrofitted" the OSI model onto the de facto stack, but you'll notice that they get a little wishy-washy at Layer 1, Layer 6, and Layer 7. Guess why? Because in the OSI Stack, there were actual protocols specified for those levels.

(definitely glad I learned the networking side of CS from folks who invented it, rather than someone who learned it later, out of a book...)

how is end-to-end crypto for jabber getting along?

Speex is open, iLBC is free (as in no royalty and documented in RFC3951). I don't know much about other voice codecs but I guess they are at least well documented (not like the MSN audio codec).

Look at Microsoft's participation in standards bodies, for a good reason why Microsoft should be allowed near the FOSS community. Take "SVG or iCAL for example. Both standards threaten Microsoft's hedgemony. Yet Microsoft is part of both standardization efforts. Both projects have been plagued by interminable delays. Whether you chalk this up to Microsoft's conciencious meddling, or merely to gross incompetance, the fact remains that Microsoft was no boon to either effort. Where are Microsoft's iCAL products? What is Microsoft doing to promote SVG?

Microsoft is a predator, and will sink to any depth to eliminate competition. Apparently, since Microsoft has ascertained that it's usual tactics don't work when combating the FOSS movement, it has decided to sleep with the enemy. If you can't beat 'em, join em, and then ruin the party. We've lost Daniel Robbins. Now they're gunning for nothing less than Linus' employer. Weasels, snakes and rats. I'm sure they can offer the OSDL all kinds of "benefits", if the ODSL would make just a few small concessions...

I posted a response to this "article" earlier today which I am just going to paste here:

Normally I try to avoid these articles, but Sharon Housley's RSS Won the Syndication Standards Battle is one I can't avoid. She claims that RSS has overtaken Atom because of support (or lack there of) for RSS by Microsoft and Google.

Sharon began by saying Microsoft had dumped Atom in favour for RSS. Is it just me or did Microsoft not say that they will support Atom almost 3 weeks ago? She says that Google News feeds having both RSS and Atom is a sign of weakness in the format, even though Google-owned Blogger (and Atom supporter) has always provided a link to FeedBurner for those who prefer RSS instead of Atom. Having both RSS and Atom on Google News isn't a sign that RSS is dominating so much as it is Google providing a choice of format to users. By the way, podcasting is not limited to RSS 2.0 as Atom supports Podcasting in a way that is arguably more powerful than RSS's. Microsoft's lists, another RSS innovation, are also easily done with Atom. Don't forget that the IETF approved the propsed Atom standard while RSS has been fragmented many times by different authors.

With Microsoft calling its support for syndication web feeds, Google refering to them as feeds on Google News and web clips on Google Desktop 2 (as Brad Hill mentions in Google Shuns the RSS Name) it seems likely that other sites will offer syndication through a generic name in more than one format. How all of this can be viewed as RSS winning any kind of standards battle is baffling.

Dana

Bullcrap

All of RSS's 9 varieties are so similar they can easily be parsed by a single parser.

Atom has currently two varieties: 0.3 (widely used, though deprecated and denounced) and 1.0 (official IETF standard, but not very widely used yet). As with RSS's varieties, these are also not strictly compatible, though are easily parsed by the same code.

Both RSS 1.0 and RSS 2.0 support HTML natively and support XHTML through extensions.

RSS 2.0 is extensible through namespaces just like RSS 1.0 and ATOM.

RSS 1.0 is based on RDF, making it IMHO more complicated than both Atom and RSS 2.0.

Atom is much better defined than RSS.

A good (though slightly biased) overview of the differences between Atom and RSS can be found here.

RSS indeed dominates the feed scene, but Atom 1.0 has just been reviewed and approved by the Atompub Working Group (part of IETF, the same group that standardized HTTP, SMTP, and many other RFCs).

Thus, I wouldn't be so quick to claim RSS' victory. Tim Bray is a big supporter of Atom, and here is recent report titled RSS 2.0 and Atom 1.0 Compared. Over at Simpy (feel free to use demo/demo account if you don't have an account yet), I am happily supporting RSS and Atom (as well as RDF).

I believe Atom also has the "push" component, and not just "pull" that RSS has. That is, I believe Atom spec contains specification of Atom as a way for making requests to web services, while RSS, I think, only lets you publish the data passively, and have clients actively pull it.
I can't find good references to this now, but maybe somebody else can find them and reply to this thread.

RSS with its 9+1 incompatible versions is hardly a standard for anything. It is a huge pain for a implementer to decide which versions to support. Microsoft decided to support (one version of) RSS for now because it has been around for longer and we know how reticent is Microsoft to everythig new. So, for Microsot, RSS is of course better then nothing.

However, it is just wrong to say that the format war is over and RSS has won. Atom is a coherent standard now being finished under the umbrella of the IETF , and it is just now just starting to catch. And it will, because many of us have had enough RSS bullshit. We already had a disscussion with the guy behind RSS 3.0 which convinced me that with guys like him writing the RSS specs (just for the love of writing), RSS is REALLY DOOMED.

It already is.

-draft-11 was approved as a standard. There are no pending issues. There will be no other draft. An RFC number and other formalities are missing, but that is just bureaucracy. The eventual RFC will not differ from -draft-11.

Welcome to the future.

that this happens on the day after the IETF announces that it's approved the ATOM syndication format?

Announcement reproduced below:

The IESG has approved the following document:

- 'The Atom Syndication Format' as a Proposed Standard

This document is the product of the Atom Publishing Format and Protocol Working Group.

The IESG contact persons are Scott Hollenbeck and Ted Hardie.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ato mpub-format-11.txt

Technical Summary:

This document describes the Atom format for syndication. It is XML-based and is considered to be the successor to the earlier RSS formats. Its primary use is for web-based content, but is expected to be used for non-web content as well, such as personal news feeds.

Working Group Summary:

Some members of the working group remain unenthusiastic about some sections of the document, but the chairs strongly believe that there is rough (or better) consensus in support of the document as a whole.
For some of the parts with the most contention, there cannot be more than very rough consensus due to basic differences in the way people would design parts of the format, particularly given that we have many models in existence with the different flavors of RSS. For some parts of the document, there is contention about whether or not a particular item should or should not be in the Atom core versus being an extension. For some parts, there is contention whether there should be MUST/SHOULD/MAY leeway for content creators in the presence or absence of an element, or the semantic content of an element; the
group really pushed RFC 2119 around during the past few months.

Protocol Quality

Scott Hollenbeck and the XML Directorate have reviewed the specification for the IESG. Test implementations have confirmed basic protocol soundness.

Why isn't gzip compression of RSS feeds part of the specification?

It is. It's part of the HTTP specification, RFC 2616. Every data format transmitted over HTTP can take advantage of it. There's no need to treat RSS as a special case.

3rd time I've posted this, sigh. slashdot depresses me a little more every day.

The only thing simple here is you!

captcha: debase

This is just wrong. Why on earth did people mod it up? I guess that's Slashdot for you.

RFC 920, back in 1984, says that "COM = Commercial, any commercial related domains meeting the second level requirements."

SecurID (the original SDTI) algorithm is flawed, as it was demonstrated by atStake, and the ACE Server protocol also has some issues. (I've collected notes about it). May be, sonsidering OATH OTP will solve the issues with the SDTI problems, but anyway perely coded Web applications (like those on the http://tools.cisco.com/ will always be a security hole.

Skype is naff because they do not allow SIP clients. http://www.ietf.org/rfc/rfc3261.txt The protocol has existed for ages, but Skype are a closed shop - another Microsoft in the making. Dump Skype and get yourself a real VOIP provider that uses SIP.

The client prepares the KRB_TGS_REQ message, providing an authentication header as an element of the
padata field, and including the same fields as used in the KRB_AS_REQ message along with several optional fields: the enc-authorization-
data field for application server use and additional tickets required by some options.

authorization-data[10] AuthorizationData OPTIONAL

From discussions with Microsoft, which were not under an NDA, the situation appeared to be as follows circa October, 1997. This information comes from the USENIX publication ;Login.

NT 5.0 will indeed use Kerberos. However, the protocol has been "extended" by Microsoft, by adding a digitally signed Privilege Attribute Certificate (PAC) to the Kerberos ticket. The PAC will contain information about the user's 128-bit NT unique id, as well as a list of groups to which the user belongs.

The NT PAC is unfortunately not compatible with the PAC's used by the Open Software Foundation's Distributed Computing Environment (DCE). It is also somewhat debatable whether the NT PAC is legal with respect to RFC-1510, the IETF Kerberos V5 protocol specification. The original intent of RFC-1510 prohibited what Microsoft was trying to do, but Microsoft found what they claimed to be a loophole in RFC-1510 specification.

Many folks, including Paul Hill and Ted T'so at MIT, as well as Cliff Neumann at ISI, have tried to work with Microsoft to find a more compatible way of doing what they wanted to do. To that end, we made changes in the upcoming revision of RFC-1510 to add a clean and compatible way of adding extensions such as Microsoft's PAC to the Kerberos ticket.

To Microsoft's credit, they agreed to change NT 5.0 to use a cleaner and more compatible way of adding extensions to the Kerberos V5 ticket ... [snip]

RFC 1510 specifies that the encrypted part of a ticket may include an optional AuthorizationData field. If the authorization-data are present, they are decrypted using the sub-session key from the authenticator. ... [specified encoding of authorization-data field follows]

Microsoft has not fully disclosed their use of the authorization data field. However some information is public knowledge at this time.... [partial, reverse-engineered microsoft encoding of authorization-data field follows]

XHTML is not HTML.

I'm not saying that it is. I'm saying that it is text/html. text/html is a media type that covers a number of different document formats, XHTML happens to be one of them.

I don't see how you can say that you can serve XHTML up as text/html

Not me. The text/html specification: RFC 2854.

I'm not trying to look trendy by saying it's not "real" XHTML, but it isn't.

Yes, it is. Labelling it as text/html does not change it from being XHTML. If you labelled it as text/plain, then that would be different, as text/plain only means one thing, plain text. But labelling it as text/html means "this document could be one of a number of different document types, one of them being XHTML".

The fact that Mozilla doesn't choose to apply XHTML rules to XHTML documents served as text/html doesn't change their nature. It's a limitation of Mozilla, and in this particular instance, it means innerHTML works where otherwise, another limitation of Mozilla would prevent it from doing so.

Furthermore, serving up XHTML documents as text/html puts the browser into quirks mode

You are mistaken there, it does no such thing.

I am not sure what the difference is between invalid and malformed - do you mean unsupported tags?

An XML parser cannot "not support" tags. You mean element types. All XML parsers support all tags.

XML parsers are required to throw fatal errors when they encounter malformed documents. Malformed documents are documents that don't follow basic XML syntax - this means things like forgetting a closing tag, or mis-nesting tags. XML parsers are not required to (and generally don't) throw fatal errors when they encounter invalid documents. Invalid documents are documents that don't follow the rules of the particular document type in question. These rules are a superset of the basic XML syntax rules - all malformed documents are invalid, but not all invalid documents are malformed.

One example of a well-formed but invalid document would be an XHTML 1.1 document that used the <font> element type. By following all the XML syntax rules like closing all elements in the right order, the document would be well-formed. But by using an element type not defined for this document type, the document would be invalid. XML parsers would not be required to throw a fatal error when processing this document, and you will find that Mozilla does not.

Oh, so you just want SIP. SIP is secure. Current deployments might not be. http://www.ietf.org/rfc/rfc3261.txt Read all those parts about SRTP, TLS and SIPS.

A complete waste of time.

A complete waste of time.

http://www.ietf.org/rfc/rfc1738.txt?number=1738

the IETF thinks differently re: URLs

>And it's URI, not URL. No such thing as a URL.

There's a whole RFC here to prove you wrong:
http://www.ietf.org/rfc/rfc1738.txt

NeoThermic

for automated publish/subscribe models because it's an actual standard.

SenderID is an extension of SPF, which is not proprietary.

A valid SPF record will be picked up by any conforming SenderID processor as a SenderID record.

The reasoning here is that MS's sender ID uses spf records, but those two types of records are not compatible:

1. There are differences in syntax between the spf record format and the ms-senderid record format. You can't parse one record using the syntax of another, but MS pretends that you can.
2. There are differences in meaning between the two records. You can't use a test meant to answer whether a specific localpart and domain is permitted by the domain holder for use in MAIL FROM and HELO arguments and go from there to assume anything about whether the same thing is true for PRA arguments. MS pretends that you can do so, but if you do, you'll get wrong answers.

Without explicit approval of the domain owner, checking other identities against SPF version 1 records is NOT RECOMMENDED because there are cases that are known to give incorrect results.

And most, if not all of those XHTML compliant buttons on websites are incorrect, since they are sending the content as text/html, which is not an XML application

text/html is not for HTML alone. It's for XHTML too. Read the RFC. It explicitly states that it is permitted to send XHTML 1.0 documents following the "compatibility profile" (Appendix C) of the XHTML 1.0 specification.

The misconception that XHTML as text/html is wrong is popular, but incorrect. It might not be a good idea for most people to serve XHTML in this way, but it's not wrong or against the specifications in any way.

As someone who once implemented ICMP (in 1982, before BSD, even), I should say something.

First, ICMP is a layer 3 protocol, like TCP and UDP. ICMP is IP protocol #1; TCP is #6 and UDP is #17.

Second, it's quite feasible to put ICMP in user space. I'm writing this on a QNX system where it's in user space. My 1982 implementation was also in user space, as part of 3COM's UNET. Linux doesn't do it that way, but it's not fundamental that ICMP must be in the kernel. It needs to have a mechanism to pass messages to the other protocols, but that's a local message passing problem. But I'm not going to rehash the ever-growing monolithic kernel issue here.

Third, we knew about many of those vulnerabilities back in the 1980s, but weren't as concerned about them because the Internet was a DoD/NSF operation. Destination Unreachable and Source Quench messages used to be taken more seriously than they are now. Destination Unreachable told you where the network was down, and Source Quench told you where it was congested, basic network management info back then. Today, nobody does network management that way and many TCP stacks don't do much, if anything, with ICMP information. I used to encourage the use of Source Quench for congestion management (see my RFC on this, from 1984), but it's far less appropriate today. Back then, we were concerned about packet loss through transmission errors, a frequent occurence with leased-line synchronous modems. So, when a packet was lost, the question was whether you should retransmit rapidly (appropriate for an error) or slowly (appropriate for congestion). Source Quench could disambiguate that situation. Today, it's assumed that packets are lost almost entirely through congestion, since the lower levels are of much better quality than they used to be.

Help me out here, I seriously want to understand you comment. How can ICMP outlined in RFC792 http://www.ietf.org/rfc/rfc0792.txt?number=792/ allow for a sequence number when it is designed as an unreliable protocol without a port number or sequence number in the header? I mean unless we rewrite ICMP as a layer four protocol I don't see how we can prevent this?

Yeah, I remember DECnet. The coolest thing about it is that it required you to have a special DECnet MAC address for every Ethernet port on each host. The good news is that this led to widespread Ethernet MAC reprogrammability...

Many moons ago I worked for DEC, and spent lots of time making VAXen play and talk to each other. The deal with the DECnet MAC address was DECnet's solution to the problem solved by ARP in the TCP/IP world.

The big problem was hooking PCs to DECnet in the days of 640k. The only available drivers for DEC's favourite homegrown officially-sanctioned NIC that worked with Windows 3.0 were for real mode only, and DEC's favourite homegrown officially-sanctioned NIC also needed a 64k segment of memory for its DMA interface. Even with QEMM and friends (remember them?), this was sometimes a challenge to make it all work, and get the relevant bits to fit in 640k.

...laura

The point of OpenID is to be dead simple, short-comings and all, so it's actually adopted.

The above is taken from a discussion of vulnerabilities. The problem with this lowest common denominator approach is that it's horribly broken. OpenID is currently no better than just giving the URL of your blog.

The number one problem is the complete lack of integrity checking. Everything in OpenID seems to be perfectly happy to let their requests be modified in transit. I think the problem with this are pretty damn obvious: nothing can be trusted. Fortunately, fixing this is pretty simple: use TLS. In today's shared hosting environment, you probably want to require support for server name indication.

Another brilliant idea: transmit the key that you'll use for signing later in plaintext.

Yes, you can ask for DH-SHA1 encryption and get back a plaintext secret. If this troubles you, don't use the handle and instead use dumb mode with that server. (and if somebody sniffed the plaintext secret, it won't matter, since you'll never accept queries using that assoc_handle). If the server can't do DH, it's probably limited in some way, but using dumb mode is still safe, if not a little slower.

I believe "limited in some way" means "completely insecure." "Dumb mode" is not safe because there's no key associated with the server, so there's no way to ensure you're talking to the same one or that someone isn't tampering.

I also don't see much point in using a symmetric key for speed and security when you're just encrypting a short string. It's so tiny that both improvements are similarly small.

Perhaps the biggest problem with OpenID is it's reliance on sending a user to another page to login. It's just too easy to spoof a page and fool most people. Even better, you can open a window using Javascript and hide the location bar. Even if you normally use TLS, most people probably won't notice if it's missing or the certificate is different. Also, most sites (including LiveJournal) include a completely insecure assurance that you're secure. For example, LiveJournal says "LiveJournal Secure Site "

A simpler and more secure alternativeThe only way to fix this is (gasp) get users to carry their own keys. If you stored your key in a bookmarklet or extension, you could sign something with it. This is completely feasible because Javascript cryptography implementation is done. You could submit your public key with the signed comment. If you wanted to associate yourself with a URL, all you need to do is link to a page with the public key. If the same public key can be used for the signature.. That's right, no special identity server is needed. The public key could be submitted directly or it can be linked to. It might be a pain to write out the entire URL to the key, so perhaps autodiscovery-from-HTML should be supported:
<link rel="openpgp.key" href="http://www.livejournal.com/pubkey.bml?user=a trustheotaku" />
Note that no TLS is needed. The signature is secure in and of itself. If you want to support all the fanciness (e.g. revocation) of OpenPGP (spec), then you just need the