Unrelated, Google's page creator rewrites an uploaded sitemap 0.90 automagically into a sitemap 0.84 removing all <lastmod> elements. Or rather it did that last week for e.g. this sitemap, maybe it's one of the experimental features.
REXX, SPF, Internet drafts
RFC 4590 contains four examples for Auth Digest. That's in essence the same as Digest-MD5 defined in RFC 2831, only based on the older RFC 2617. The examples were apparently copied as is to RFC 4590bis drafts. I've added the 2*2 (INVITE+rspauth, GET+rspauth) examples to md5.cmd (1.1).
The RFC 4590 examples still fail in my MD5 test suite, or rather my attempt to guess the used password failed. There's also an oddity in these examples not yet supported by the REXX script:
RFC 2617 states that a client sending any
qop= parameter, for the RFC 4590 examples that's
qop=auth, MUST also send a
cnonce= (client nonce) together with a
NC= (nonce counter). In the RFC 4590 examples the client doesn't do that, causing a trap in my REXX script.
There are two plausible ways to fix this, either use the RFC 2069 fallback algorithm, or simply omit the missing NC and CNONCE. In simplified REXX the second solution would be:
return MD5( HA1 || ':' || NONCE || ':auth:' || MD5( XURL ))
The first (2069) solution would use a colon : instead of :auth:. The "official" RFC 2617 string instead of :auth: is:
':' || NC || ':' || CNONCE || ':' || QOP || ':'
Other variants of what RFC 4590 actually wants could be to use an empty CNONCE with a dummy NC in the direction of :00000001::auth:. As always Digest-MD5 is messy.
Related, an old 2069-erratum still rots in the pending errata mbox. I'm now confident that the 2069-code in md5.cmd works at least with the IETF tools server. I've not yet submitted an erratum for RFC 2983, three out of four 2983-examples are fine.
- The default position of the search form on the result page is "left" set by AH:left. Fans of the old free site search form know this "Align Header" parameter, it's (kind of) documented on my lab page. It's also straight forward to modify it, add ;AH:center to the cof=FORID:0 parameter, where 0 might be something else depending on the used form.
- The free site search result pages show my logo immediately above the search form. The used parameters L: for the logo URL and S: for the site URL are still the same for CSEs, it's only not more necessary to specify all these odd values as part of the cof= parameter, Google inserts them on the fly. Unfortunately it also uses some CSS magic (style sheets) to get this right, failing miserably with browsers not supporting CSS. After some experiments I found the culprit: There's a new LP:1 "Logo Position" , this has to be disabled by LP:0 to get the desired effect.
<input type="hidden" name="cof" value="FORID:0;AH:center;LP:0" />
leo-dict.xml uses Content type html for Googlets with target="_top" as required by LEO, resulting in an <iframe> on an iGoogle-page or wherever it's used. Of course this only works with browsers and devices supporting <iframe>.
A misrepresentation of some ß uses in upper case head lines, on books, and on tombstones resulted in a proposal to add an "upper case ß" to Unicode as code point u+1E9E (PDF).
I've got a warning that this PDF might crash some PDF viewers, but exceptionally AcroReader 3 survived this attack.
The next likely step could be demands to permit ß in I18N domain labels because it suddenly got an upper case variant.
Of course there's also the "minor" problem of upgrading fonts and software for a fictitious "upper case ß" worldwide, as far as they support German.
- ► 2011 (25)
- ► 2008 (26)