Re: [netmod] namespace encoding in draft-ietf-netmod-yang-json-02

On Thu, Dec 11, 2014 at 12:08 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Andy Bierman <andy@yumaworks.com> writes:
>
>> Hi,
>>
>> Sec 4 has changed the rules for module names:
>>
>>    Names with namespace identifiers in the form shown in Figure 1 MUST
>>    be used for all top-level YANG data nodes, and also for all nodes
>>    whose parent node belongs to a different namespace.  Otherwise, names
>>    with namespace identifiers MUST NOT be used.
>>
>>
>> So it is a protocol error if a prefix is used twice in a row:
>>
>>    /A:foo/A:bar     --> causes a protocol error and MUST be rejected
>>    /A:foo/bar MUST be used instead
>>
>> IMO this is very fragile and does not follow the Postel Principle.
>
> I don't agree it is fragile. The rule for deciding about the presence or
> absence of a namespace ID is robust and dead simple: compare the
> namespaces of the current node and its parent - if they differ, add the
> namespace ID.
>

It is not robust at all.
If the correct prefix is provided it should be accepted.
That would be robust.  Rejecting an identifier for using
the correct prefix for a node is fragile, and quite counter-intuitive
for anybody familiar with XPath.

>> In this example the server knows module 'A' and it is the correct
>> module for node 'bar'.  Yet it MUST reject the input according
>> to the new rules.
>>
>> I prefer these rules:
>>
>>    - The namespace for a node MUST be uses in top-level
>>      nodes and if the namespace is changing.
>>    - If no prefix is present, then the namespace associated with
>>      the parent node is used
>>
>
> This would be useful for senders that want to skip making the above
> decision a instead attach namespace IDs to all names. But this just
> shifts the burden to the receiving side.
>

The receiver already has to check for a prefix so I do not see
any burden.  It is an added burden to check the prefix
and decide it is invalid just because it is redundant.

>> IMO it is too much work for the server to verify that
>> a prefix is not used. Parsing a prefix is not a burden,
>
> I don't think it is difficult, see above.
>
>> since the code to parse the prefix must be already there.
>
> Parsing is one thing and comparing the namespace ID with the parent is
> another. With the existing rules, the namespace change is signalled in a
> much clearer way.
>

That encoding is also accepted.
Redundant information is not the same thing as incorrect information.
The receiver must be liberal in what it accepts.  Rejecting redundant
but valid data does not follow the Postel Principle.

>>
>> It is also more hassle on clients that are constructing URLs
>> from multiple functions. They have to know which prefix
>> MUST NOT be used.
>
> I am not sure I understand the part about multiple functions but IMO
> constructing an URL could still be very simple if it is done from left
> to right: The namespace is on the first component and then whenever it
> changes.
>
> Lada
>
>>
>>
>>
>> Andy
>>

Andy

>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C