Re: [lp-wan] FWD: Draft SCHC for CoAP -Title

[Laurent Toutain <[e-mail]>]

Hi,

I would not like to reopen a long debate; this is the only step before an
RFC and drink some beers.

I understand the RFC8724 got a long and subtile name with framework and
fragmentation on it since it reflects the reality. For 8824, it like "SCHC
for CoAP" with and without acronym expansion, it's simple and officialize
the fact that SCHC become a name and we will not continue to say some long
paraphrases.

Laurent



On Thu, Jun 3, 2021 at 1:50 PM Pascal Thubert (pthubert) <[e-mail]>
wrote:

> Hello Ana
>
>
>
> I thought we agreed that we’d refer to SCHC as a framework to indicate it
>  includes compression and fragmentation.
>
> This term framework is really weird. Seems everyone understands it in a
> different way. .. If someone has the official definition I’m interested!
>
> Also, we now insist that we can compress the L7 if people want to. So why
> should we insist on “header”? That’s where it started but that’s not where
> we are now, it is?
>
>
>
> Keep safe;
>
>
>
> Pascal
>
> *From:* lp-wan <[e-mail]> *On Behalf Of *Ana Minaburo
> *Sent:* jeudi 3 juin 2021 11:10
> *To:* [e-mail]; [e-mail];
> [e-mail]
> *Cc:* Eric Vyncke (evyncke) <[e-mail]>; [e-mail]
> *Subject:* [lp-wan] FWD: Draft SCHC for CoAP -Title
>
>
>
> Dear Dominique, Carles, and Pascal, and all,
>
>
>
> I take this discussion out from the RFC-Editor Subject, if not I will be
> lost again.
>
>
>
> We agree to eliminate the term LPWAN from the title during the interim
> meeting, and I've answered the RFC-Editor with this option that I like:
>
> Full-extended:
>
> "Static Context Header Compression and Fragmentation (SCHC) for
> Constrained Application Protocol (CoAP)"
>
> Full-abbreviated:
>
> "SCHC for CoAP"
>
>
>
> I'm afraid I have to disagree with Dominique's proposition in two things.
> First, starting with Compression, the title is ambiguous because it can be
> interpreted as data compression and no header compression. Second, I'm not
> sure SCHC is a framework, or neither it becomes one.
>
>
>
> Dominique proposition: "Compression of the Constrained Application
> Protocol (CoAP) using the Static Context Header Compression and
> fragmentation (SCHC) framework"
>
>
>
> Cheers,
>
> Ana
>
>
>
> ---
>
>
>
> >From: *Pascal Thubert (pthubert)* <[e-mail]>
> >Date: Wed, Jun 2, 2021 at 11:14 AM
> >Subject: RE: [AD] Re: AUTH48 [LB]: RFC 8824
> <draft-ietf-lpwan-coap-static->context-hc-19.txt> NOW AVAILABLE
> >To: [e-mail] <[e-mail]>, >
> [e-mail] <[e-mail]>, Eric Vyncke (evyncke) <[e-mail]>
> >Cc: [e-mail] <[e-mail]>, [e-mail]
>
> ><[e-mail]>, [e-mail]
>
> ><[e-mail]>
>
> >
> >
> >Perfect!
>
> >
>
> >>From: *Carles Gomez Montenegro* <[e-mail]>
> >>Date: Wed, Jun 2, 2021 at 11:02 AM
> >>Subject: Re: [lp-wan] [AD] Re: AUTH48 [LB]: RFC 8824 <draft-ietf-lpwan-
>
> >>coap-static-context-hc-19.txt> NOW AVAILABLE
> >>To: <[e-mail]>
> >>Cc: Pascal Thubert (pthubert) <pthubert=[e-mail]>, >>
> [e-mail] <[e-mail]>, Eric Vyncke (evyncke) <[e-mail]>, >>
> [e-mail] <[e-mail]>, [e-mail]
>
> >><[e-mail]>, [e-mail]
>
> >><[e-mail]>
>
> >>
> >>
> >>Hello Dominique, (all,)
> >>
> >>I support your proposal below!
> >>
> >>In my opinion, it addresses nicely the comment being considered.
> >>
> >>Cheers,
> >>
> >>Carles
>
> >>
>
> >>
>
> >>
>
> >>
>
> >>
>
> >>
>
> >>>From: <[e-mail]>
> >>>Date: Tue, Jun 1, 2021 at 5:14 PM
> >>>Subject: RE: [AD] Re: AUTH48 [LB]: RFC 8824
> <draft-ietf-lpwan-coap->>>static-context-hc-19.txt> NOW AVAILABLE
> >>>To: Pascal Thubert (pthubert) <pthubert=[e-mail]>,
> >>>[e-mail] <[e-mail]>, Eric Vyncke (evyncke) <[e-mail]>
> >>>Cc: [e-mail] <[e-mail]>,
> [e-mail]
>
> >>><[e-mail]>, [e-mail]
>
> >>><[e-mail]>
>
> >>>
> >>>
> >>>Hello authors, all,
> >>>
> >>>Following our interim meeting today, here is my contribution to
>
> >>>comment 3 by RFC Ed
> >>>> 3) <!-- [rfced] Abstract and subsequent:  "SCHC compression",
>
> >>>>where
> >>>> used generally as a noun, looks odd.  We suggest rephrasing where
>
> >>>>appropriate.
> >>>>
> > >>>We see that RFC 8724 defines "SCHC" as "Static Context Header
> >>>> Compression and fragmentation".  Because this document defines
>
> >>>>"SCHC"
> >>>>as "Static Context Header Compression", "SCHC compression"
>
> >>>>would then
> >>>> read as "Static Context Header Compression compression".
> >>>>
> >>>> Should we expand "SCHC" as "Static Context Header
>
> >>>>Compression and
> >>>> fragmentation" per RFC 8724, instead of using the current "Static
> >>>> Context Header Compression"?  That would solve the "Static
>
> >>>>Context Header Compression compression" situation. -->
> >>>
> >>>This document should not redefine SCHC.
> >>>Hence, I propose the following
> >>>- Full title
> >>>"Compression of the Constrained Application Protocol (CoAP) using
> >>>the Static Context Header Compression and fragmentation (SCHC)
> >>>framework"
> >>>- Abstract
> >>>"This draft defines how to compress the Constrained Application
> >>>Protocol (CoAP) using the Static Context Header Compression and
> >>>fragmentation (SCHC) framework. SCHC defines a header >>>compression
> mechanism tailored for Constrained Devices."
>  >>>- Introduction, 2nd paragraph
> >>>"[RFC8724] defines the SCHC famework, which includes a header
> >>>compression mechanism for the LPWAN network, based on a static
> >>>context."
> >>>
> >>>With the above changes, which are consistent with RFC8724 and are
> >>>inline with the RFC Editors suggestion, "SCHC compression" no >>>longer
> looks odd, and the 25 instances can remain unchanged.
> >>>
> >>>Best regards
> >>>
> >>>Dominique
> >>>
>