Jack Schwartz wrote:
> Hi everyone.
>
> I am fixing bug
> 4325 Implement data types for A/I criteria on server side
>
> which is to allow the criteria manifest to list MAC addresses with or
> without colons, and IP addresses with or without periods. (This is
> because currently, both addresses are allowed in the manifest only
> without any punctuation.)
>
> This fix is intended to be temporary, with the "real" fix going in as
> 6620 Multiple XML parsers are used in the slim_install gate
>
> For this bug, I plan on validating the data, and then stripping off the
> punctuation from the addresses as part of the validation process. This
> way, code changes are minimal to the rest of AI, which already expects
> punctuation-less addresses.
>
Since it appears to me that it will simplify things quite a bit here,
please just remove the "punctuation-less" variant from being supported
in the schema. They're not (and never were) useful.
Dave
> There are a few ways I could fix this bug:
>
> 1) Check against schema patterns with and without the dots or colons.
> For IP addresses, this is just fine, because there is only one address
> to check. For MAC addresses, a range must be accommodated. This means
> that combinations of starting and/or ending MAC addresses need to be
> validated. There are 9 combinations since start and end can both be one
> of ("None", with colon, without colon)). Since the (None x None)
> combination isn't allowed, that reduces to 8. The main problem comes
> when two addresses are specified and one is buggy. The buggy one will
> be interpreted as a string and will thus errantly pass validation. A
> more minor issue is that the pattern is long and cannot be divided into
> multiple lines, and so it is messy. Python code is used only to strip
> the punctuation, and so is small (~ 50 lines including function header
> and comments).
>
> 2) Don't use the schema, and just treat these addresses like strings.
> Do validation in python code. This keeps the schema looking cleaner,
> and the python code isn't that long (under 100 lines commented, for both
> types of addresses). The problem here is that a range entry with two
> strings must be accommodated, compromising other criteria which use lists.
>
> 3) Allow the manifest to list only one address if a range is not
> desired, and two if a range is desired; and use the schema. This gets
> past the problem of buggy strings slipping through validation, and cuts
> down on the number of combinations to list in the schema (one for a
> single entry, one for a range, when the <choice> option is used.)
> Drawbacks: the minor issue of the long pattern will remain. Another is
> that users will see a change. Not sure if there are other implications
> for other parts of AI.
>
> My vote is (3) if it is feasible, but would like others with more
> knowledge of AI to chime in. Is (3) the best solution to others who
> know AI well?
>
> Thanks,
> Jack
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
