-----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 protected] Professional email: [email protected] 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----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
