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

[Oscar Novo <[e-mail]>]

Thanks Peter!

Oscar 

-----Original Message-----
From: Peter Saint-Andre [mailto:[e-mail]] 
Sent: 13. tammikuuta 2011 3:01
To: Robert Sparks
Cc: Oscar Novo; [e-mail]; Gonzalo Camarillo
Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19

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/