Re: [Lager] Stephen Farrell's Discuss on draft-ietf-lager-specification-11: (with DISCUSS and COMMENT)

[Alexey Melnikov <[e-mail]>]

Hi Stephen,
I think I will need help from the WG on more subtantial issues, but I
will quickly reply to a couple of your DISCUSS points (WG should feel
free to correct me if I am wrong):

On Thu, Apr 21, 2016, at 11:24 AM, Stephen Farrell wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-lager-specification-11: Discuss

 [snip]

> This spec is tackling a hard problem, (machines doing what
> humans do to classify identifiers), and as a result there are
> some tricky bits here. That inherently hard problem has thrown
> up a few things I'd like to discuss (though the 1st one is
> easy:-)...
> 
> (1) section 5: this says code points MUST be 4 hex digits.
> What is s/w supposed to do if it sees only 2 hex digits?
> Should it ignore the range or char element or fail to process
> the entire LGR document?

I don't mind clarifying this, but in general it means that the whole
document is syntactically invalid and thus must be ignored.

I don't think it is very common for IETF documents to specify error
handling when a MUST is violated, but of course it is not prohibited.

> I think the same issue applies to
> other uses of 2119 language as well, (e.g. "MUST be treated as
> an error at the end of p19), so I'd recommend you state some
> kind of general rule if you can.
> 

 [snip]

> (3) 6.3.4: While recursion is said to be disallowed, the "for
> which the complete definition has not been seen" is pretty odd
> for an XML specification, as it means that you need a full
> ordering for the elements in the document (or at least within
> the <rules> element).  That means if some editor decodes from
> disk and then encodes to disk, you need to be sure that the
> order is preserved or else you break the "has been seen"
> constraint. (And if you do that, then you're allowing rules to
> mutually refer to one another, which brings us back to discuss
> point 2.) 7.4 maybe has a similar issue. I think for this you
> could simply state up front that these XML documents MUST NOT
> be re-ordered during editing. (Or else add some kind of
> attribute to help with ordering which seems ickky.)

Correct me if I am wrong, but I haven't seen any XML generator that
reorders XML elements, unless they understand XML schema for a
particular XML document. So by default order of XML elements withing
parent elements is fixed, so I don't think this is an issue.

Best Regards,
Alexey