BEGIN:VCALENDAR
METHOD:PUBLISH
CALSCALE:GREGORIAN
VERSION:2.0
BEGIN:VEVENT
TZ:-8
UID:4409CE8F-A356-CEED-4CE9-BB7BF582D831
DTSTAMP:20100909T085853Z
DTSTART;TZID=US/Pacific:20061116T192700
SUMMARY:What compliance means to an engineer
DESCRIPTION:I've been seeing the word "compliance" tossed around a lot for HTTP and other standards lately, with much ambiguity. Let's say you read RFC2068 and implemented a client very carefully.  Does it make your client implementation "uncompliant" if a new standard updates or obsoletes RFC2068 and adds requirements, as RFC2616 did? My answer is "that's not even a meaningful question". Compliance can be a very loose concept. 	If your software claims compliance to HTTP, there can be a lot of variation in how that actually works because different versions of HTTP have significant differences. 	If your software claims HTTP/1.1 compliance, we have a somewhat better idea what that means. A client advertising HTTP/1.1 support in its requests can be assumed to understand the "Cache-Control" response header from the server, because all the specs that ever defined HTTP/1.1 (RFC2068 and RFC2616) define that header. However, we can't tell if such a client supports the "s-maxage" directive on the Cache-Control header (the maximum age allowed for a shared cache entry) because that was only defined in RFC2616. 	If your software claims RFC2068 compliance we don't know whether it understands "s-maxage", but we can assume that it supports "maxage". 	If your software...
DURATION:PT1H
END:VEVENT
END:VCALENDAR