Re: [Cbor] Status of CBOR CRS Specification

[Chris Lemmons <[e-mail]>]

I have not received any responses to my attempts to reach out to
Trevor, including on both linkedin and by email. I am alas unable to
locate any other contact methods. I would like to pick this up and get
it completed, but I don't know what the protocol here is. I'm
uncomfortable either submitting a draft without his name on it as an
author or with his name and without his permission. If someone has
another contact method, I'd love to get in contact with him, but I
can't seem to reach him. What's the right way to move forward here?

On Mon, Mar 20, 2023 at 12:30 PM Chris Lemmons <[e-mail]> wrote:
>
> There's a few things. For one, it's a little strange to have a
> normative dependency on a draft document. It's not clear what happens
> if the group picks up the draft and publishes it with a different
> meaning.
>
> But inside the document itself, it also says, "This tag may also be
> encoded just after tag 103 as a way of associating a CRS with a
> specific Geographic Coordinate." Perhaps I'm not understanding what
> the text meant there, but you can't generally just "add a data object"
> after another data object. They'd have to be in an aggregate of some
> sort, like an array or a map in order to be well-formed. I think array
> could work, but we'd have to define one. Instead, what I'd probably do
> is take "scoping" away from this tag entirely, simply let it represent
> a CRS and let applications define how they know to what it applies.
>
> And then, for my purposes (and possibly useful to others), I can
> define a "CRS Wrapper" that is a two-element array with the first
> element being "the CRS" and the second element being "an object
> described by the CRS". This prevents any parser from parsing an object
> that is supposed to be scoped by the CRS without understanding the
> wrapper. With the "CRS comes after the object", a parser reading a
> coordinate could misinterpret it if it ignores the CRS that comes
> after it. "Unwrapping" would need to be intentional, so an application
> can decide what it wants to do. Second, having the Wrapper be a
> separate tag means that if someone registers another tag that has a
> coordinate system meaning (for example, a tag that represents a
> coordinate system on a different planetary body), it would be just as
> valid in the first position and parsers could reuse the same structure
> if they needed support for that.
>
> Technically, we could combine the Wrapper and the CRS all in one tag,
> if we really wanted, since it would add an array data object meaning
> (it currently uses unsigned int and text string). It's not my general
> inclination, but that's probably a matter of preference. It does have
> a low allocation number, so a bit of conservation isn't a bad thing,
> all other things being equal. If the working group picked it up, it's
> something that could be discussed. :)
>
> And last, it could use some language cleanup. It says "basic numeric
> type (CBOR Major type 0)", which might confuse someone who sees
> "number" in common CDDL things and isn't sure on first reading if it
> included floats or negative numbers. It could say "unsigned integer"
> to match the definition in RFC 8949 and reduce potential confusion.
> The introduction promises things like "You will learn [about Datum]
> further below," but never actually discusses it. It's a draft, so this
> makes sense, but it's something we'd want to improve if we were
> publishing it. I suspect a careful review might find other stuff I
> missed.
>
> On Fri, Mar 3, 2023 at 3:07 PM Carsten Bormann <[e-mail]> wrote:
> >
> > On 3. Mar 2023, at 19:39, Chris Lemmons <[e-mail]> wrote:
> > >
> > > I emailed the author directly about it a month ago, but didn't get a
> > > response. It's quite possible that they've got more pressing things to
> > > attend to or just missed my message.
> >
> > Right.  Let’s spend a little more effort in trying to find Trevor — mail is so unreliable these days.
> >
> > > As for whether it's useful to have an RFC, that's an interesting
> > > question. I'd probably have done a mere registration for this one, but
> > > it's already three-quarters done as a draft. It's not a ton of work to
> > > just get it over the finish line.
> >
> > Can you give us a hint how you would evolve this specification?
> >
> > I think anything that would just extend what you can do with 104 (without changing the meaning of what you already can do) should be fine.
> > Or we could go ahead and do a new tag as well that does have changes in meaning.
> >
> > Grüße, Carsten
> >
> >
> > >
> > > On Fri, Mar 3, 2023 at 6:09 AM Carsten Bormann <[e-mail]> wrote:
> > >>
> > >>
> > >>
> > >>> On 2023-03-03, at 13:53, Michael Richardson <[e-mail]> wrote:
> > >>>
> > >>> Signed PGP part
> > >>>
> > >>> Chris Lemmons <[e-mail]> wrote:
> > >>>> This leaves me with two options: define a new tag fit for precisely the
> > >>>> purpose I need, or see if there's interest in finishing the work that
> > >>>> was started with Tag 104. It does seem like having two tags, especially
> > >>>> with one in the low-numbered space, is not ideal.
> > >>>
> > >>>> The draft is here:
> > >>>> https://datatracker.ietf.org/doc/draft-clarke-cbor-crs/
> > >>>
> > >>>> For context, I need a CRS tag that can "wrap" other content to describe
> > >>>> the CRS for that which it encloses. I can define it as necessary, but
> > >>>> reuse is usually better. Is there any interest in picking up the work
> > >>>> of Tag 104? Is this even an appropriate venue for that?
> > >>>
> > >>> I think that CBOR is the right place for this.
> > >>> Try reaching out to the author, T.Clarke @ Ball.  If he doesn't have time to
> > >>> pursue this document and make you a co-author, then we have the XML for it,
> > >>> and could just take it over.  Once adopted, document authors serve at the
> > >>> pleasure of the wg chairs, so changing authors isn't a problem.
> > >>> (just have to give credit where it is due)
> > >>>
> > >>> It's possible to do new tags in ~1 year as evidenced by RFC9164 and 9277.
> > >>> (Actually, I think they could have happened even faster)
> > >>
> > >> If it is useful to have an RFC, this is correct; a mere registration can be done much more quickly.
> > >>
> > >> Grüße, Carsten
> > >>
> > >>
> > >> _______________________________________________
> > >> CBOR mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/cbor
> > >
> > > _______________________________________________
> > > CBOR mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/cbor
> >