[media-types] moving forward with

[Erik Wilde <[e-mail]>]

hello.

On 2016-09-26 19:20, Mark Baker wrote:
> Ah, I hadn't forgotten all about RFC 7464. Yes, registering the suffix
> in that light makes ample sense. Thanks, Erik.

https://tools.ietf.org/html/draft-wilde-json-seq-suffix seems to be 
reasonable enough that nobody has objected to it. we would like to move 
forward with this so that we can use it for a media type that we are 
working on in the GeoJSON working group.

what is the best way to move forward? as requested by 
https://tools.ietf.org/html/rfc6838#section-6, i have created a 
registration template here:

https://tools.ietf.org/html/draft-wilde-json-seq-suffix-00#section-4

i am including this registration template literally to help the review 
process via [e-mail]:

----------------------------------------

       Name: JSON Text Sequence

       +suffix: +json-seq

       References: [3]

       Encoding considerations: See [3]

       Fragment identifier considerations: The syntax and semantics of
       fragment identifiers specified for +json-seq SHOULD be as
       specified for "application/json-seq".  (At publication of this
       document, there is no fragment identification syntax defined for
       "application/json-seq".)

          The syntax and semantics for fragment identifiers for a
          specific "xxx/yyy+json-seq" SHOULD be processed as follows:

             For cases defined in +json-seq, where the fragment
             identifier resolves per the +json-seq rules, then process as
             specified in +json-seq.

             For cases defined in +json-seq, where the fragment
             identifier does not resolve per the +json-seq rules, then
             process as specified in "xxx/yyy+json-seq".

             For cases not defined in +json-seq, then process as
             specified in "xxx/yyy+json-seq".

       Interoperability considerations: n/a

       Security considerations: See [3]

       Contact: Applications and Real-Time Area Working Group
       ([e-mail])

       Author/Change controller: The Applications and Real-Time Area
       Working Group.  IESG has change control over this registration.

----------------------------------------

assuming [e-mail] review ends favorably, i guess i'll need a 
shepherd for this document to move it through the RFC pipeline? what's 
the best process to find one, or does anybody volunteer?

thanks a lot and kind regards,

dret.

-- 
erik wilde | mailto:[e-mail] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |