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

[[e-mail]]

Hello Ana,

Don’t be afraid to disagree ;-) , but let me argue anyway.


-          I buy your argument that compression at the beginning of my proposal is ambiguous, and I suppose “header compression” would too long. I can’t think of anything better at this point in time.


-          SCHC is a framework, sorry, it’s too late to disagree about this one. It’s written in the title of RFC8724 (https://www.rfc-editor.org/info/rfc8724)

Another point : my proposal had a lower case f, but an RFC title must have capitalized initials, so go for a F.
But in the abstract, please use lower case f like in RFC8724.
That was the outcome of our long discussion in Spring 2020 when we were in AUTH48 phase for 8724.

Best regards

Dominique


From: lp-wan [mailto:[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]<mailto:[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]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, >[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Eric Vyncke (evyncke) <[e-mail]<mailto:[e-mail]>>
>Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]>
><[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]>
><[e-mail]<mailto:[e-mail]>>
>
>
>Perfect!
>
>>From: Carles Gomez Montenegro <[e-mail]<mailto:[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]<mailto:[e-mail]>>
>>Cc: Pascal Thubert (pthubert) <pthubert=[e-mail]<mailto:[e-mail]>>, >>[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Eric Vyncke (evyncke) <[e-mail]<mailto:[e-mail]>>, >>[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]>
>><[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]>
>><[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>, >>>[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Eric Vyncke (evyncke) <[e-mail]<mailto:[e-mail]>>
>>>Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]>
>>><[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]>
>>><[e-mail]<mailto:[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
>>>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.