On 9/5/11 1:54 PM, "Dave Cridland" <[email protected]> wrote:
>>> Let's say that we add (yet) another attribute to the caps element, >>> indicating that the "new" restrictions are in place. (These might include >>> the various restrictions mentioned in this thread). >>> >>> Now, when a client sees a caps marked as restricted, it can validate the >>> disco#info it gets. >>> >>> If a client sees two caps strings, one marked as restricted and one not, it >>> should assume that the caps string is intended to be restricted as proceed >>> accordingly. >> >> That's a fairly interesting idea. More thinking required. >> >> > Right, it's not a fully fleshed-out solution, for sure. Granted I might not have read the entire thread closely enough, I don't think anyone has suggested the massive-hack approach recently: REQUIRE marker entries that always sort to the end of each section, perhaps by starting with a nice high codepoint. PROHIBIT any entry that sorts higher. REJECT (and negatively cache) any response that doesn't meet these criteria. You might even choose a different marker entry for each section. Old software would still work. New software could decide how much policy to enforce. -- Joe Hildebrand
