Re: [Asdf] shepherd comments on draft-ietf-asdf-sdf-16.txt

[Michael Richardson <[e-mail]>]

Carsten Bormann <[e-mail]> wrote:
    >> 1) I think we need some text in the Introduction explaining "SDF 1.0" and
    >> "SDF 1.1".
    >>
    >> I suggest: "During the development of SDF, version numbers were included, but
    >> with the publication of this base SDF and the associated extension process,
    >> they are no longer relevant. "

    > All references to SDF development draft version numbers were removed in
    > 0becec2, which was part of PR #130, which was incorporated to -16.  Is
    > this comment part of an earlier review?

No, I'm saying that I think that we need to explain to reviewers that might
have seen the version info, that we did away with it.

    >> 2) I found the terminology rather abruptly started talking about JSON and
    >> maps and the like, and since I've intentionally not read much for six
    >> months, I had no basis on which to understand this.  I think the
    >> Introduction might need to diagram how SDF is encoded before we can start
    >> talking about Quality, etc.
    >>
    >> For instance:
    >> (Note that JSON maps are often called JSON objects due to JSON's
    >> JavaScript heritage; in this document, the term Object, short for
    >> sdfObject, is specifically reserved for the above grouping, even
    >> if the type name "object" is imported from a data definition
    >> language with the other semantics.)
    >>
    >> seems really out of place in the Terminology.
    >> Maybe alphabetical terminology is wrong, and top-down would be better.

    > The terminology isn’t alphabetical (but it is not exactly top-down
    > either — the intent was to have a good sequence for reading).

Yeah, I prefer a good sequence for reading to be smarter, but then reviewers
always get upset.

    > Maybe we should pull forward SDF Document and SDF Model.

I think so.

    >> 3) Figure 2 has the sdf* in some arrangement, but I am not sure if there is some
    >> logic to it.  I guess the double line at the bottom is a UML thing?
    >> Ah. The SVG version is significantly different, having arrows and the like.
    >> I think that the ASCII version may be sufficiently content-free as to be omitted.

    > Interesting.  (I hadn’t looked at the plaintext version for a while.)
    > These diagrams are generated by plantuml, and maybe there has been a
    > version update that needs some tweaks...

If we can't fix it, then we might just omit the diagram from the ascii, as I
don't think it actually contributes much without all the arrows.

    >> "Base SDF does not address internationalization of given names."
    >> okay. And we don't permit UTF-8 either.  Should we permit UTF-8, but then
    >> restrict use to ASCII, so that tools will know to expect UTF-8?

    > (SDF’s strings, in interchange, are represented as UTF-8.
    > Given names are strings, but then limited to ASCII digits, ASCII
    > letters, and $.  So I think we already have what you are suggesting?)

Yeah, I think that I'm saying that tooling should expect to process UTF-8,
even if the tool should then reject things that aren't digits/letters/$.
Probably this is true (a no-op) for JSON libraries in ruby, python,
rust... but C-libraries might be surprised.

    >> 4) section 4.1:
    >>
    >> Global names look exactly like https:// URIs with attached fragment
    >> identifiers.
    >>
    >> There is no intention to require that these URIs can be dereferenced.
    >>
    >> I feel that some maybe IESG will get upset about this.
    >> Well, maybe just ART ADs, and they will get first kick at the can anyway.

    > That’s why we have draft-bormann-t2trg-deref-id :-)
    > But seriously, considerations for dereferenceable identifiers are
    > collected in that document, and here we shouldn’t second-guess this.

that's fine with me then; I'm just concerned about ratholes from ART reviews from HTTP types.

    >> "this specification" under enum... does that refer to SDF 1.0, or to JSO?.

    > the SDF specification (actually even in 1.1, but we are not getting
    > specific about pre-base SDF versions any more).

Okay, I didn't mean to write "1.0"  (or 1.1) here, but was confused about SDF
for JSO when I read those sections.

    >> 8) I think that we'll need some covering text to explain how we are using
    >> JSO, and yet not really depending upon it.  Is our "version" of JSO7 unique?
    >> My impression is that we are using a subset of it, but then we add stuff like
    >> "const".... I'm worried we'll get into proceedural snags here (again).  It's not
    >> our intention to standardize JSO within the IETF, and yet... those appendixes
    >> are there looking like they want to be normative.
    >> Can I implement without reading JSO?

    > The appendices are normative.  JSO is just mentioned as the inspiration...

So if one can implement without reading the JSOx documents, then I fear that
our normative appendices have just become the RFC reference for JSO, and
might get reviewed as such.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [





--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide