-1 on the features draft

[Tim Bray <Tim.Bray@xxxxxxx>]

Pardon me for coming to this party late.

1. The basic mechanism for specifying features seems sound.
2. I've noted a few little editorial glitches.
3. Section 5, about digital signatures, has no place in this document  
and really needs to be removed.
4. The mechanism for specifying features needs to be decoupled from  
the initial list of features.  A substantial number of the features  
here are wide-open roll-out-the-red-carpet invitations to violations  
of Postel's law.  I believe that APP server implementations bloody  
well SHOULD accept content type="text | html | xhtml", otherwise what  
was the point of building all that machinery into 4287.  Some of the  
features represent *absurd* micromanagement ("XHTML Rights"?!?! gimme  
a #%$%! break). There are 30, count 'em *THIRTY* ways provided here  
for the server to damage interoperability and make client authors'  
lives impossible.  If I were a client author, I would be highly  
disincented to implement this because I'd have to write thousands of  
lines of code to work around all the corner cases that could fall out  
of the combination of one feature with another.

Frankly, I'm shocked; I'd have assumed that an initial draft would  
have specified a couple of things like drafts and If-Match and so on,  
not this laundry list of miscellaneous hypotheticals.  As it stands,  
it creates the condition where wildly non-interoperable  
implementations can easily wave the APP flag.

I'd quickly become an enthusiastic +1 if this were reduced by about  
75% so it specified a mechanism for specifying features, and maybe  
one or two basic non-controversial features.

Now on to details.

======================================

3. A feature is an abstract behavior, function and capability supported
   by an Atom Publishing Protocol collection.

Um, shouldn't that be "behavior, function, *or* capability"?
and should it say "which may be supported"?

=========================================

"Some features supported by a collection might not require that the
   client take any specific action when interacting with the server.
   For such features, the "required" and "preferred" support levels
   SHOULD be considered to be synonymous with "supported"."

... say what?  I totally don't get it.  Maybe an example?

===========================================

"The f:feature element MAY contain attributes included as part of the
   atomCommonAttributes production defined by Section 2 of [RFC4287] or
   any update thereof."

That "any update thereof" is that kosher in the IETF?  This language  
makes me nervous, and may be seen as constraining people doing  
hypothetical future revs of 4287.

=============================================

"When used on an f:feature element, such
   attributes serve the same purpose described in [RFC4287] or their
   corresponding specifications."

Hmm, I think "... or their corresponding specifications" is a little  
muddy here. Do you mean "revisions of RFC4287" or are you asserting  
that if you see any old namespaced attribute, you ought to do  
whatever its specification says you ought to do?

==============================================

  " It is important to point out that implementors who add "required"
   features to existing collections can cause existing client
   applications to fail"

You mean "existing client applications that support this features  
specification to fail".    To be fair, the next para covers this, but  
the wording as given is in fact wrong.

================================

"   When multiple, potentially contradictory features are specified such
   that the support level for one is marked as "preferred" and the
   others are "supported", clients SHOULD use the "preferred" feature."

It seems really questionable to try to micromanage the behavior of  
clients which are confronted with an egregiously broken service  
doc.   Just declare that it's an error to be contradictory.  Or even  
better, take the whole notion of "contradictory" out of the spec and  
let the market sort it out.

==================================

5. Digitally Signing Service Documents

   Because the mechanisms defined in this specification can be used to
   compel client applications to implement certain behaviors when
   interacting with a collection, implementors who specify required
   features are encouraged to sign Service Documents containing the
   features extension using an Enveloped Signature, as described by  
XML-
   Signature and Syntax Processing [W3C.REC-xmldsig-core-20020212].

-1.  This is ridiculous.  Every service doc constrains client  
behavior in all sorts of ways; this spec advances no plausible  
arguments why this spec adds an extra level of magic that suddenly  
requires signatures.  This entire section mixes fishes and bicycles  
and needs to be removed.

================================

8.1.1 Several of the descriptions need a re-write; e.g. "indicates  
that the collection does not accept entries that provide XHTML in the  
atom:content element" really means "does not accept entries where the  
content element has a "type" attribute whose value is "xhtml".  Let's  
be precise, please.