Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19

[Peter Saint-Andre <[e-mail]>]

On 1/12/11 1:32 PM, Robert Sparks wrote:

> I'll ask the xml directorate to review how we're restating 4575's
> schema. (Has such a review already been performed?). One question I
> have is whether this is a normative update to 4575 as written.

I'll volunteer to look at that topics and other XML matters (probably
next week).

>>> /------------------------Question-------------------------------------
>>>>
>>>>
>>>>
>>> 
* In the Schama in section 5, there are several comment blocks
>>>> instructing someone to redefine something as <empty/> or
>>>> <notAllowed> (no trailing slash?).  Is this an established
>>>> convention documented somewhere? If so, can you provide a
>>>> pointer? If not, please add text explaining who the
>>>> instructions are intended for and when they should be invoked.
>>>> 
>>>> [ON] The Data Model is an extensible schema. We just indicate
>>>> to the implementor how to limit the schema if it's not
>>>> extended. The trailing slash has been included in the
>>>> <notAllowed> element.
>>> 
>>> [RObert] Then,  please add text explaining who the instructions
>>> are intended for and when they should be invoked.
>>> 
>>> [ON1] Is not the current text self-explanatory? Which
>>> instructions would you suggest?
>> 
>>> [Robert] No, it's not self-explanatory - if it were, we wouldn't
>>> be having this conversation. I suggest pulling it into an
>>> "Implementer note", introducing the note with a sentence or two
>>> explaining that this is something you can do if you know >>you
>>> are not going to use any extensions.
>> 
>> [O] Right, what about adding the following text in every
>> extensibility elements?
>> 
>> "If extensions (check section 6) beyond this specification are not
>> used, re-define anyAttribute as <empty/> and remove the definition
>> below"
>> 
>> Would it be clear adding the text above?
> 
> Thinking about this some more, I believe this is dangerous, and is
> not something we should recommend as part of standardizing this
> model. Basically, you're saying that an implementation that believes
> it isn't going to exercise an extension point can stub those
> extension points out. In practice, this will result in incompatible
> versions of the schema being fielded, and in the worst of cases, when
> the implementer was _wrong_ about this implementation (or the things
> around it) wanting to use the extension points, results in a brittle
> system. We certainly can't prevent an implementer from making this
> simplification if they choose to do so, but it's a hazardous practice
> that is very likely to make rolling out extensions in the future more
> difficult.
> 
> I think you should remove the comments from the document altogether.

I agree with Robert here.

As a point of comparison, in XMPP we have many extension points. In some
environments, the deploying organization wishes to lock down the service
so that only particular extensions are allowed (say, only a small set of
known stream features during initial negotiation). And one way that such
organizations lock down the service is by performing schema validation
on all of the XMPP traffic, using a schema that removes ability to
extend the protocol at certain points. However, although we know that
some organizations do this, I don't think it's the kind of thing we'd
want to recommend or encourage, at least not in the core specification
for an XML protocol or format that by definition includes the extension
points.

Just my gram of silver...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/