Re: -1 on the features draft

[James M Snell <jasnell@xxxxxxxxx>]

Bill de hOra wrote:
> [snip]
>>
>> If you have a better proposal, I’d love to hear it.
> 
> Here: ww.xmpp.org, www.beep.org, www.fipa.org, www.w3.org/2001/sw/.
> They've done much groundwork in terms of machine driven negotiation. You
> could look at SSL/TLS handshaking as well I guess.
> 

I'd be better swayed by a concrete example of how you would imagine
these alternative approaches working with Atompub.

Also, keep in mind that the features draft is not about feature
negotiation, it's about feature discovery.. or more specifically, it's
about the server telling the client what implementation choices it has
made so that the client can make up its mind about what it's going to do
before it tries to do it.

> In particular, each sentence is called "feature" hence the feature spec.
> But the overall effect is a language that can be used to define private
> protocols tunneled over Atompub. I'm betting that language will suck,
> and if it doesn't, it will be a coincidence given its implicitness.
> 

Again, the f:feature element does not define anything.  Yes, the
f:feature element can be used to document the stupid choices people
might make when implementing their servers but that doesn't, by any
stretch of the imagination, legitimize those stupid choices.

Let's take f:feature out of the picture for a minute.  Based solely on
the options defined by the two Atom WG produced specifications, I can
create a compliant Atompub implementation that:

  a. Requires the use of a vendor-specific authentication scheme,
     even one that does not use the RFC2617 mechanisms
  b. Requires the use of vendor-specific extensions, even ones that
     may not be adequately documented
  c. Requires that text constructs be limited to plain text
  d. Requires that content elements contain only specific kinds of
     content, including vendor-specific and potentially IPR-laden
     formats
  e. Forbids the use of certain standardized or commonly-used extensions
  f. Requires the use of vendor-specific app:control elements

The list can go on and on.  Given just the two WG-produced drafts I can
**already** create private protocols tunneled over Atompub.  Using the
f:feature element as currently defined does not make it any easier to do
so.  Using the f:feature element does not legitimize or encourage such
behavior.

You may not agree that such implementations are really "Atompub" but I
can guarantee that you cannot back up that argument with any spec
language.

Now, I am not encouraging or defending this behavior at all.  Quite the
contrary, I've consistently argued against the proliferation of
vendor-specific extensions, behaviors, etc.  All that I am saying is
that everything you seem to be afraid of is already possible, with or
without the f:features draft.

It's not the features spec that allows folks to define private protocols
on top of Atompub, it's Atompub's inherent flexibility and lack of
conformance rules that allows folks to define private protocols on top
of Atompub.

> 
>>> The mU thing is flawed, there's no way to express how features
>>> relate to each other; in combination they represent point to
>>> point wins at expense of overall fragility.
>>
>> Stopping the features draft won’t reduce fragility unless a
>> better proposal exists. Vendors will make something up if they
>> have to, and if you think the features draft is bad, just *wait*
>> to see what *they* come up with.
> 
> Pleading about what vendors will and won't do doesn't sway me; If I did

And yet you're entire argument seems to be based on what you're afraid
vendors might do with the f:feature element.

Final point...

No one is arguing that required features do not make things more
fragile. No one is arguing that implementors won't royally screw things
up if given half the chance. And no one is arguing that there are some
really stupid ways of implementing this stuff.  There is absolutely no
need for this thread to dwell on those themes any longer.

What we are saying is that there needs to be a way of documenting the
implementation choices a server has made so that client applications can
either properly configure themselves to communicate with a server or can
determine whether such communication is possible in the first place.
That mechanism needs to be able to take into consideration the
considerably-wide range of implementation choices servers can make as
defined by the Atom RFC's.  If the f:feature element is not a good way
of doing this, then let's talk about some concrete counter proposals.
If you do not agree that anything is needed here, then fair enough.

- James