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

[Stephen Farrell <[e-mail]>]

On 23/04/16 12:49, Alexey Melnikov wrote:
> 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. 

That's a fine answer.

> 
> 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.

Well, in this case the error might only affect checking some labels
and not others, so I guess folks may be tempted to use the rest of
the LGR if the spec doesn't say to fail to load the LGR on such errors.

> 
>> 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.

I'm happy to be corrected, but this was a big (and painful) deal
for xmldsig, so I'm not sure why it'd not be an equal PITA here;-)

Cheers,
S.

> 
> Best Regards,
> Alexey
>