Subject: [lp-wan] SCHC RFC-to-be title?

From: <[email-masked]>
Date: Thu, 6 Feb 2020 09:55:00 +0000

Hello all,

This was discussed yesterday at the interim meeting and I want to give everybody a chance to chime in.
The SCHC draft is currently in AUTH48 stage, with the RFC Editor, and now is the time to do the last editorial changes.

One thing we want to do right is the RFC title. It currently says "Static Context Header Compression (SCHC) and fragmentation for LPWAN, application to UDP/IPv6".
We want to change it for a better title, one that reflects the most important contributions of this RFC.

  *   I believe the UDP/IPv6 section is secondary, it's more of an example of application. Having UDP/IPv6 in the title distracts from the fact that the rest of the draft is a generic mechanism, IMHO.
  *    We have a little tension between using SCHC as an acronym (expliciting Compression) and the use of expressions like "'SCHC Fragmentation" and "SCHC Compression".
  *   Thoughts have been expressed that the applicability of the generic SCHC algorithm is not limited to LPWANs, therefore it should not appear in the title. The rest of the text could still say that "SCHC was originally developed with LPWANs in mind".
  *   Thoughts have been expressed that "static context" is a distinguishing feature, and as such, it should stay in the title.

Can I please get your votes about the following two points:

A) "SCHC"
A.1 remains an acronym meaning "Static Context Header Compression", and we live with the tension described above.
A.2 becomes the acronym to mean "Static Context Header Compression and fragmentation", even though the F does not show in the acronym
A.3 becomes SCHCF and means "Static Context Header Compression and Fragmentation", and we will later figure a pronunciation for it.
A.4 becomes a proper noun, a name that is not spelled out. The text can still mention that the name originated as an acronym for "Static Context Header Compression".

B) RFC title:
B.1 "SCHC: generic framework for header compression and fragmentation using a static context"
B.2 "SCHC: static context header compression and fragmentation for Low-Power Wide Area Networks (LPWANs)"
B.3 ""Static Context Header Compression and fragmentation (SCHC)"
B.4 ""Static Context Header Compression and fragmentation (SCHC) for Low-Power Wide Area Networks (LPWANs)"
B.5 suggest your own!

Your votes by the end of the week would be very much appreciated!
Thanks

Dominique & the co-authors gang

_________________________________________________________________________________________________________________________

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.

---

From: Laurent Toutain <[email-masked]>
Date: Thu, 6 Feb 2020 11:51:36 +0100

A.2 B.4

On Thu, Feb 6, 2020 at 10:55 AM <[email-masked]> wrote:

> The SCHC draft is currently in AUTH48 stage, with the RFC Editor, and now
> is the time to do the last editorial changes.
>
> One thing we want to do right is the RFC title. It currently says "*Static
> Context Header Compression (SCHC) and fragmentation for LPWAN, application
> to UDP/IPv6*".
>    - I believe the UDP/IPv6 section is secondary, it's more of an example
>    of application. Having UDP/IPv6 in the title distracts from the fact that
>    the rest of the draft is a generic mechanism, IMHO.
>    -  We have a little tension between using SCHC as an acronym
>    (expliciting Compression) and the use of expressions like "'SCHC
>    Fragmentation" and "SCHC Compression".
>    - Thoughts have been expressed that the applicability of the generic
>    SCHC algorithm is not limited to LPWANs, therefore it should not appear in
>    the title. The rest of the text could still say that "SCHC was originally
>    developed with LPWANs in mind".
>    - Thoughts have been expressed that "static context" is a
>    distinguishing feature, and as such, it should stay in the title.
>
> A.2 becomes the acronym to mean "Static Context Header Compression and
> fragmentation", even though the F does not show in the acronym
> A.3 becomes SCHCF and means "Static Context Header Compression and
> Fragmentation", and we will later figure a pronunciation for it.
> A.4 becomes a proper noun, a name that is not spelled out. The text can
> still mention that the name originated as an acronym for "Static Context
> Header Compression".
>
> B) RFC title:
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Feb 2020 11:38:16 +0000

A2B3

No point limiting to LPWAN !

Regards,

Pascal

Le 6 févr. 2020 à 10:55, "[email-masked]" <[email-masked]> a écrit :

Hello all,

A) "SCHC"

B) RFC title:

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Thu, 6 Feb 2020 12:41:00 +0100

Hi,

My vote is also for A.2 and B.4.

Thanks,

Carles

>> A.1 remains an acronym meaning "Static Context Header Compression", and
>> we
>> live with the tension described above.
>> 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,
>> This message and its attachments may contain confidential or privileged
>> information that may be protected by law;

---

From: Arunprabhu Kandasamy <[email-masked]>
Date: Thu, 6 Feb 2020 13:43:32 +0100

Hi Dominique,
Thanks for listing the options.

My vote is for `A2B4`.

-- 

<https://t.sidekickopen05.com/s1t/c/5/f18dQhb0S7lM8dDMPbW2n0x6l2B9nMJN7t5X-FfhMynW4Wr-Yl7d-0fCW56dGqW1GQ8t2102?t=https%3A%2F%2Fackl.io%2F&si=7000000001059340&pi=5991da3d-efb6-4959-f4d5-a627f1b5eb8b>

*Arunprabhu KANDASAMY *R&D Engineer-IPCore
+33 2 22 06 05 77

www.ackl.io

 <https://www.linkedin.com/company/acklio/> [image:
W3Schools] <https://twitter.com/acklio>

---

From: Ana Minaburo <[email-masked]>
Date: Thu, 6 Feb 2020 14:18:13 +0100

Hello! with no limits

A2 B3

Ana