Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (4)

From: Cullen Jennings <[email-masked]>
Date: Tue, 26 Apr 2011 14:30:26 -0600

Added some text to fix this but did not enforce in the relaxNG. 

On Mar 15, 2011, at 10:51 AM, Marc Petit-Huguenin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 03/14/2011 04:56 PM, Cullen Jennings wrote:
>> 
>> On Jan 10, 2011, at 5:17 PM, Marc Petit-Huguenin wrote:
>> 
>> More comments:
>> 
>> A.30. Section 5.5.4.1 "opaque config_data<0..2^24-1>"
>> 
>> If a configuration document contains multiple configuration elements (and I
>> guess multiple matching signature elements), then should not config_data been in
>> fact structured the same way than kinds?, i.e. an XML fragment containing only
>> the configuration element and the signature element for this overlay, extracted
>> from the multiple configuration elements document?
>> 
>> See also A.31 below.
>> 
>> A.31. Section 1.1 'The file can contain multiple "configuration" elements..."
>> 
>> This contradicts the RELAX NG grammar in section 10.1.1.  In addition, should
>> not configuration elements be structured as kind elements are, i.e. something
>> like this:
>> 
>> <overlay>
>> <configuration-block>
>>   <configuration>...</configuration>
>>   <signature>...</signature>
>> </configuration-block>
>> <configuration-block>
>>   <configuration>...</configuration>
>>   <signature>...</signature>
>> </configuration-block>
>> </overlay>
>> 
>> In this case, config_data would contain a XML configuration-block production
>> (see A.31 above)
>> 
>>> I changed the grammar to allow
>> 
>> <overlay>
>> 
>>   <configuration>...</configuration>
>>   <signature>...</signature>
>> 
>>   <configuration>...</configuration>
>>   <signature>...</signature>
>> 
>> </overlay>
>> 
>>> I like the config-block would be better but it would break existing stuff so I made the grammar match the existing text which seemed to allow the above. Thoughts on what we should do here? I have no strong opinion - fundamentally they are both about the same. 
> 
> Having no config-block makes this fragment valid:
> 
> <overlay>
>  <configuration />
>  <configuration />
>  <configuration />
>  <signature />
>  <signature />
> </overlay>
> 
> But in fact I am withdrawing my suggestion in A.30 to use the config-block in
> the ConfigUpdateReq, instead of the whole overlay:  There is nothing that
> prevent an implementation to send a document with only one configuration and
> signature element in the ConfigUpdateReq, even if the document retrieved from
> the configuration server contains more than one.
> 
> So my suggestion would be to keep thing as they are, but add text that explain
> the configuration/signature elements should be interleaved and that a signature
> element applies only to the configuration element immediately preceding.
> Perhaps enforcing this in the RelaxNG schema could also be a good thing.
> 
> - -- 
> Marc Petit-Huguenin
> Personal email: [email-masked]
> Professional email: [email-masked]
> Blog: http://blog.marc.petit-huguenin.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iEYEARECAAYFAk1/mSQACgkQ9RoMZyVa61d/dQCeNobyVwaCD6N9Co+gGytx3swd
> kpkAn0qLyJqgnMuygjIhsfgGZATawC0f
> =opRp
> -----END PGP SIGNATURE-----