Re: [Cbor] Status of CBOR CRS Specification

[Chris Lemmons <[e-mail]>]

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
>