Re: Clarifying text and spec completeness

Roy,
	Some responses inline.

At 5:22 PM -0800 1/28/05, Roy T. Fielding wrote:
>
>Ted, while I agree with your advice, it is also inappropriate for
>a working group chair to insist that their own comments take
>priority over the opinion of the document authors and stated
>opinions of the people reviewing the documents on the mailing list.
>While such might be a reasonable position for a technical error or
>security-related issue in the specification, it is not appropriate
>for a matter of editorial preference.  When the IETF process is
>ignored, discussion will inevitably begin to heat.

One of the charges the IETF gives to a working group is to
ensure that the work meets the charter.  If the working group
chair or chairs believe it doesn't meet the charter (an implementable,
interoperable spec covering subject $FOO being a common
charge), it is her/his/their job to push.  Getting pushed back
is a part of the job too.  Failing to be collegial in one's behavior
during all of this pushing is not one of options.

So, everyone, please push carefully.

>>As a bit of AD guidance, let me tell the group that the IESG has in my term
>>rarely asked for the removal explanatory or clarifying text and has
>>quite often asked for an increase in such text.  This is a reflection
>>of the increased complexity of some of our standards and the
>>likelihood that those implementing a follow-on standard will not
>>have been those that implemented the original.
>
>The IESG should not allow independent specifications to define the
>behavior of other protocols, particularly when those other protocols
>are at a higher level in the standards process.  They certainly did
>not allow me to fix some of the bugs in MIME while I was defining HTTP.

This is absolutely correct.  But having a spec point to or excerpt
those specs to get guidance in front of the implementors does not
define those protocols, it highlights relevant issues.  That's not
a redefinition.

>>As a concrete example with bearing on these discussions, while the text
>>related to e-tag handling in the XCAP specifications might, in 
>>theory, be entirely
>>derived from other aspects of that spec or the underlying 
>>technologies, I and others
>>felt that it would be valuable to make the behavior explicit in the 
>>XCAP specs.
>>This was done with explanatory text and appropriate references to the
>>underlying specifications.  Making it overt also makes it far 
>>easier, to put it
>>bluntly, for us to tell if the spec gets it wrong.  That can be handy.
>
>Sorry Ted, but that is an excellent example. The XCAP specification
>is so long that I hadn't bothered to read it, which is a pity
>given that it is entirely dependent on two specifications for which
>I did most of the authoring.  We should have learned that mistake
>from RFC 2616.
>
>I'll note, having just looked at draft-ietf-simple-xcap-05
>Section 7.10, the description of etag makes it impossible for
>XCAP documents to be managed by modern content management
>applications (like those based on JSR 170) that are already
>based on XML content trees.  In other words, your "valuable"
>explicit behavior is both wrong and damaging to XCAP deployment
>and should never have been placed in that spec.

We should have this discussion on the SIMPLE mailing list, where
specific behavior for e-Tags was discussed extensively.  I believe
that the behavior they have specified is a restricted profile of
the permitted behaviors for e-Tags; that, at least, is the intent.
If you can demonstrate that the behavior they have specified
is *not permitted* by the base spec, then please say so to the
authors/IESG now.  The document is not yet out in the wild.

That said, I also believe we have to take specs and look at their
applicability as we evaluate them; some aspects of the work
of the IETF is to build building blocks of very general applicability
and some is to build protocols with narrow ranges of application.
XCAP was created for a very specific set of deployments, and in those
deployments the behavior specified not only makes sense, the WG
saw it as pretty close to optimal.  What scare me is the presumption
that XCAP will be generalizable, and that people will believe it is
a more general content management system.  The same choices
that made sense for managing a buddy list for a cell phone client
are lousy for managing a full-fledged XML data store.  But that doesn't
make the first one a task we shouldn't take on.

			regards,
				Ted Hardie

Received on Saturday, 29 January 2005 01:51:50 UTC