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

A.2 B.4

On Thu, Feb 6, 2020 at 10:55 AM <dominique.barthel@orange.com> wrote:

> 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.
>
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan
>