Subject: Re: [secdir] Secdir review of: draft-wilde-json-seq-suffix

From: Warren Kumari <[email-masked]>
Date: Fri, 09 Dec 2016 15:48:36 +0000

[ Top-post ]

Ok, thanks for the explanation and updates -- I'm fine with the document
now that I understand some of the history, etc.

Part of what threw me was that I write IANA considerations as instructions
to the IANA instead of writing it the way you did (e.g I would write "The
IANA is requested to add the "+json-seq" structured syntax suffix to the
registry at <URL> with the following information"  instead of "IANA has
added the following "+json-seq" structured syntax suffix to its registry of
structured syntax suffixes"...)

A quick skim of RFC 5226 doesn't really say which is the right thing, but
RFC 7322, section-4.8.3 implies that writing it as instructions is
"correct" ("The RFC Editor will update text accordingly after the IANA
assignments
have been made.") -- anyway, this is bike-shedding, etc.

W

On Mon, Nov 28, 2016 at 1:00 PM Erik Wilde <[email-masked]> wrote:

> hello.
>
> thanks a lot for the review!
>
> On 2016-11-28 05:34, Alexey Melnikov wrote:
> > On 28/11/2016 13:16, Warren Kumari wrote:
> >> I don't see any *security* issues, but the document is very unclear.
> >> It *looks* like it just tries to add "+json-seq" to the IANA
> >> Structured Syntax Suffix Registry, but I don't see why it is Standards
> >> Track, or why it need to be an RFC at all;  the registry is Expert
> >> Review, and RFC 6838 Section 6 seems clear.
> > While this indeed can be just sent in an email, IMHO, it is better to
> > register Media Type suffixes in RFCs. All existing Media Type suffixes
> > were registered in RFCs.
> > It probably doesn't need to be Standards Track.
> > I would be happy to follow IESG's advice on how to handle this document.
>
> https://github.com/dret/I-D/commit/8694a1efce71dcb96410be3bd6be8d0373383703
> switches the draft to experimental. to be honest, i do get conflicting
> info on this, and depending on the people dealing with a draft, some
> seem to prefer one status over the other. i have no strong opinion about
> this and thus i am happy to switch to the status people think is most
> appropriate.
>
> > This suffix was incorrectly being used in a media type registration, so
> > this document is now trying to register the suffix to fix the brokenness.
>
> that is the only reason this draft exists: register the suffix in a way
> that it is properly defined and registered and that the registration can
> be referenced. so yes, this is a simple draft, and intentionally so.
>
> >> Other issues:
> >> It does not contain a Security Considerations section, and there are a
> >> number of broken references (e.g: it says: "Online access to all
> >> versions and files is available on github [2]." - but [2] is a link
> >> to: http://www.rfc-editor.org/info/rfc6838)
> > Yes, this needs to be fixed.
>
> that's the good old xml2rfc bug that still is around. sorry for this,
> https://github.com/dret/I-D/commit/ee5838e5ddf53cf7084022abb7a275ac4a30a028
> is the best workaround there is for this bug, afaict.
>
> https://github.com/dret/I-D/commit/1efd188ff60f2dbe7f414082d730091e803faa77
> fixes another broken reference.
>
> >> It is a -00, submitted Sept 23rd 2016, and the document on which it
> >> was based (draft-json-seq-suffix-00) was also a -00, submitted Sept
> >> 19th 2016. The only changes between the 2 are the metadata (name,
> >> date). There has been basically no discussion (at least, that I can
> >> find), closest
> >> is:
> https://mailarchive.ietf.org/arch/search/?email_list=art&index=AxC0J7zxKU_wH1jOrkZ0ZZUUcs4
> ?
> > The document is rather trivial (and yes, it does contain annoying
> > omissions). Chairs of GeoJSON WG reached out to me for AD sponsoring of
> > this document, because one of their documents used the prefix
> incorrectly.
>
> all correct, and apologies for missing these things so far.
>
> - the two versions exist because i accidentally named the initial
> submission incorrectly. the current version simply was a re-submission
> with the fixed submission name.
>
> - i will submit a -01 version with the changes discussed in this message
> today.
>
> - apart from the missing security considerations section (added via
> https://github.com/dret/I-D/commit/f57746b52ffc9d9b89b3af392be41c80ba530743
> ),
> is there anything else that seems to be missing?
>
> >> I *think* that it is simply trying to add "+json-seq" to the IANA
> >> Structured Syntax Suffix Registry
> >> (
> http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml
> )
> > Yes.
> >> -- unfortunately it does this very poorly.
>
> that indeed is the only intent of this document.
>
> >> It starts off by saying (note tense): "IANA has added the following
> >> "+json-seq" structured syntax suffix to its registry of structured
> >> syntax suffixes established by [2]".
>
> that's how it's supposed to read once approved (at which point the
> addition will have been done), and that's how i have written this in
> previous documents.
>
> >> [2] references to RFC 6838 - "Media Type Registration", which creates
> >> a number of registries - while looking I found
> >> "http://www.iana.org/assignments/media-types/media-types.xhtml", which
> >> does indeed have "json-seq". Because of the "IANA has added" I assumed
> >> that this was what was being referenced.
>
> RFC 6838 established more than one registry. one is that of media types.
> another one is that of structured syntax suffixes. it is that latter one
> that is targeted by this document:
>
>
> http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml#structured-syntax-suffix
>
> this one does not have the "+json-seq" structured syntax suffix in there
> and the goal of the document is to add it. this registry is specifically
> called out in the IANA considerations section.
>
> >> The IANA considerations section needs work...
>
> in which particular way? the section says that it updates the structured
> syntax suffixes registry and contains all the necessary fields to do
> that. what are you missing?
>
> >> Nits:
> >> Section 1:
> >> how a media type can signal that it is based on another media type as
> >> [O] way of how a media type can signal [P] way for a media type to
> >> signal [R] readability; original was a bit awkward
>
> thanks!
> https://github.com/dret/I-D/commit/672780ac2aafd2732e696ae85dec72e9c315ddc7
>
> >> Section 3:
> >> Applications encountering such a media type then can either simply
> >> [O] then can either
> >> [P] can then either
> >> [R] readability
>
> thanks!
> https://github.com/dret/I-D/commit/f4d915490f1b05551b9b424f3b9e69b617de3645
>
> https://tools.ietf.org/html/draft-wilde-json-seq-suffix-01 is the
> updated version of the draft. once again, thanks a lot for the review
> and feedback, this is greatly appreciated!
>
> cheers,
>
> dret.
>
> --
> erik wilde | mailto:[email-masked] |
>             | http://dret.net/netdret    |
>             | http://twitter.com/dret    |
>
>