Hi Bruno, John Scudder was kind enough to provide extensive argumentation offlist on why something along these lines should be done. We'll work on a proposal. The length indicator is a neat idea, thanks for sharing.
Job On Fri, 18 Nov 2016 at 17:32, <[email protected]> wrote: > > > > From: Job Snijders [mailto:[email protected]] > Sent: Friday, November > 18, 2016 1:46 AM > > > > On Thu, Nov 17, 2016 at 04:28:50PM +0000, [email protected] > wrote: > > > I support the draft. > > > I also support Jeff's idea to re-use existing sub-code(s). > > > > Thanks for your support. Based on the feedback received so far the next > > version of this draft will recycle Cease subcode 2. > > > > > 1 possible comment: the length of the "Shutdown Communication" field > > > seems implied from the length of the data field, rather than being > > > explicitly indicated. > > > > The text is explicit about the length: > > > > "followed by a freeform UTF-8 encoded string with a REQUIRED maximum > > length of 128 octets. " > > > > and further: > > > > "This document tries to minimize the effects of visual spoofing by > > allowing UNICODE only where local script is expected and needed, and > > by limiting the length of the Shutdown Communication." > > > > > If so, it seems that we are closing the possibility to advertise > > > additional data/usage, in some future. What about adding a TLV format? > > > > I object to using a TLV. Don't forget this is already at a TLV level: > > Cease NOTIFICATION. If one would want to define a TLV inside this TLV, a > > new Cease subcode can be requested from IANA. > > What if someone needs to advertise additional info to an existing cease > subcode? cf Jeff's email regarding the pain of changing subcodes. > So let's forget about the TLV. What about just adding the length of the > string? This would still allow adding fields after the string, while having > a negligible/null cost? > > Kind regards, > -- Bruno > > > Kind regards, > > > > Job > > > _________________________________________________________________________________________________________________________ > > 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. > >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
