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

All,
My vote is A1 B5.
Regards,

             Diego

Le jeu. 6 févr. 2020 à 11:01, Alexander Pelov <a@ackl.io> a écrit :

> Hi all,
>
> Thanks Dominique !
>
> (chair hat off)
>
> A side observation - I think that SCHC cannot be changed at that point, as
> it has already been used across other organizations and standardisation
> bodies. So, that ship has definitely sailed, and SCHCF is not an option in
> my opinion.
> Another observation - although I feel that we might come up with something
> different, I do not have problems with the current title.
>
> Then, on the point of "can SCHC become a noun?" - is something I am not
> sure we can decide. How does something stop being an acronym and becomes a
> widely-accepted term?
> For a short example - take a look at the RFC page of Wikipedia still
> states that RFC means "Request for Comments" (
> https://en.wikipedia.org/wiki/Request_for_Comments ).
> Also, I feel that for the sake of a title, it is not worth it to have to
> explain every time that SCHC is not an abbreviation, but it used to mean
> Static Context Header Compression, but because we have also fragmentation,
> we made it a noun.
> In all future references I personally will be referring it to The SCHC
> standard, or RFC 8724. I don't expect it to ever get into a long discussion
> with anyone about what is in the title ;)
>
> I would therefore vote for a simplicity - A.1.
>
> On the title, I actually like the new proposals, and if need be would go
> with a variant of B.1, where SCHC is expanded;
> "Generic Framework for Static Context Header Compression (SCHC) and
> Fragmentation"
>
>
> So, in order of preference, I would add:
> *A.1 SCHC is Static Context Header Compression*
> *B.5 Generic Framework for Static Context Header Compression (SCHC) and
> Fragmentation*
> *B.6 Static Context Header Compression (SCHC) and fragmentation for LPWAN,
> application to UDP/IPv6 *
>
> Cheers,
> Alexander
>
>
>
> On Thu, Feb 6, 2020 at 1:51 PM <dominique.barthel@orange.com> wrote:
>
>> My vote is for A.4 B.1
>> Best regards
>>
>> Dominique
>>
>> De : lp-wan <lp-wan-bounces@ietf.org> on behalf of Dominique Barthel <
>> dominique.barthel@orange.com>
>> Date : Thursday 6 February 2020 10:55
>> À : "lp-wan@ietf.org" <lp-wan@ietf.org>
>> Objet : [lp-wan] SCHC RFC-to-be title?
>>
>> 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.
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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
>>
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan
>

-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125