Subject: [AVTCORE] IDNits issue with draft-ietf-avtcore-multi-party-rtt-mix-12

From: Bernard Aboba <[email-masked]>
Date: Wed, 10 Feb 2021 00:01:48 -0800

Just ran IDnits on the document and got an error (see below).  Can you fix
the issues and resubmit the document?

idnits 2.16.05

tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt:
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1351): Unexpected
reference format: '...         ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1353): Unexpected
reference format: '...         ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1355): Unexpected
reference format: '...         ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1358): Unexpected
reference format: '...         ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1361): Unexpected
reference format: '...         ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1363): Unexpected
reference format: '...         ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1365): Unexpected
reference format: '...         ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1368): Unexpected
reference format: '...         ...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1689): Unexpected
reference format: '...    |[Bob...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1691): Unexpected
reference format: '...    |[Eve...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1694): Unexpected
reference format: '...    |[Bob...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1697): Unexpected
reference format: '...    |[Eve...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1698): Unexpected
reference format: '...    |[Bob...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1707): Unexpected
reference format: '...    |[Ali...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1711): Unexpected
reference format: '...    |[Eve...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1714): Unexpected
reference format: '...    |[Ali...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1719): Unexpected
reference format: '...    |[Eve...'
tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1721): Unexpected
reference format: '...    |[Eve...'

 - The draft-hellstrom-avtcore-multi-party-rtt-source state file is
not from today.
   Attempting to download a newer one...
 - Success fetching draft-hellstrom-avtcore-multi-party-rtt-source state file.

 - The draft-ietf-avtcore-multi-party-rtt-mix state file is not from today.
   Attempting to download a newer one...
 - Success fetching draft-ietf-avtcore-multi-party-rtt-mix state file.

 - The draft-ietf-mmusic-t140-usage-data-channel state file is not from today.
   Attempting to download a newer one...
 - Success fetching draft-ietf-mmusic-t140-usage-data-channel state file.

 - No rfc0007 state file. Attempting to download it...
   Failure fetching the file, proceeding without it.

 - No rfc006 state file. Attempting to download it...
   Failure fetching the file, proceeding without it.

 - No rfc009 state file. Attempting to download it...
   Failure fetching the file, proceeding without it.

 - No rfc0098 state file. Attempting to download it...
   Failure fetching the file, proceeding without it.

 - The rfc2028 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc2028 state file.

 - The rfc2198 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc2198 state file.

 - The rfc3550 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc3550 state file.

 - The rfc4102 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc4102 state file.

 - The rfc4103 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc4103 state file.

 - The rfc4353 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc4353 state file.

 - The rfc4566 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc4566 state file.

 - The rfc4575 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc4575 state file.

 - The rfc4579 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc4579 state file.

 - The rfc5194 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc5194 state file.

 - The rfc5630 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc5630 state file.

 - The rfc5764 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc5764 state file.

 - The rfc6263 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc6263 state file.

 - The rfc6429 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc6429 state file.

 - The rfc7667 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc7667 state file.

 - The rfc7675 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc7675 state file.

 - The rfc8634 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc8634 state file.

 - The rfc8643 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc8643 state file.

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

     (Using the creation date from RFC4103, updated by this document, for
     RFC5378 checks: 2004-06-15)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

     IETF Trust Legal Provisions of 28-dec-2009, Section 6.c(iii):
        This document may contain material from IETF Documents or IETF
        Contributions published or made publicly available before
        November 10, 2008.  The person(s) controlling the copyright in
        some of this material may not have granted the IETF Trust the
        right to allow modifications of such material outside the IETF
        Standards Process. Without obtaining an adequate license from the
        person(s) controlling the copyright in such materials, this
        document may not be modified outside the IETF Standards Process,
        and derivative works of it may not be created outside the IETF
        Standards Process, except to format it for publication as an RFC
        or to translate it into languages other than English.

  -- The document date (15 December 2020) is 56 days in the past.  Is this
     intentional?

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Missing Reference: 'Bob' is mentioned on line 1427, but not
     defined
'|[mix][Bob] And I on Wednesday evening.        | |...'

  == Outdated reference: draft-ietf-mmusic-t140-usage-data-channel has been
     published as RFC 8865

  ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'T140'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'T140ad1'

     Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--).

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 10 Feb 2021 17:14:36 +0100

Bernard,

Yes, I can and will resubmit with the issues fixed.

However, one warning was because the nits check found what looks like a 
reference in brackets, but is part of a symbolic screen picture example 
containing a source label for text in brackets.

This was the warning:

==================================================================
  == Missing Reference: 'Bob' is mentioned on line 1427, but not
      defined
'|[mix][Bob] And I on Wednesday evening.        | |...'
===================================================================

May I keep the format of this picture as it is?

Regarding the comment about pre-RFC5378 work, I have the required grants 
to the BCP78 rights.

Thanks,

Gunnar

Den 2021-02-10 kl. 09:01, skrev Bernard Aboba:
> Just ran IDnits on the document and got an error (see below).  Can you 
> fix the issues and resubmit the document?
> idnits 2.16.05
>
>
> tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1351): Unexpected reference format: '...         ...'
> tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1353): Unexpected reference format: '...         ...'
> tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1355): Unexpected reference format: '...         ...'
> tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1358): Unexpected reference format: '...         ...'
> tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1361): Unexpected reference format: '...         ...'
> tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1363): Unexpected reference format: '...         ...'
> tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1365): Unexpected reference format: '...         ...'
> tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1368): Unexpected reference format: '...         ...'
> tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1689): Unexpected reference format: '...    |[Bob...'
> tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1691): Unexpected reference format: '...    |[Eve...'
> tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1694): Unexpected reference format: '...    |[Bob...'
> tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1697): Unexpected reference format: '...    |[Eve...'
> tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1698): Unexpected reference format: '...    |[Bob...'
> tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1707): Unexpected reference format: '...    |[Ali...'
> tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1711): Unexpected reference format: '...    |[Eve...'
> tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1714): Unexpected reference format: '...    |[Ali...'
> tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1719): Unexpected reference format: '...    |[Eve...'
> tmp/draft-ietf-avtcore-multi-party-rtt-mix-12.txt(1721): Unexpected reference format: '...    |[Eve...'
>
>   - The draft-hellstrom-avtcore-multi-party-rtt-source state file is not from today.
>    https://trustee.ietf.org/license-info  <https://trustee.ietf.org/license-info>):
>    Checking nits according tohttps://www.ietf.org/id-info/1id-guidelines.txt  <https://www.ietf.org/id-info/1id-guidelines.txt>:
>    Checking nits according tohttps://www.ietf.org/id-info/checklist  <https://www.ietf.org/id-info/checklist>  :
>       https://trustee.ietf.org/license-info  <https://trustee.ietf.org/license-info>  for more information.)
>

-- 
Gunnar Hellström
GHAccess
[email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 10 Feb 2021 09:37:04 -0800

You might consider using () instead of [] to avoid confusing IDnits.

On Wed, Feb 10, 2021 at 8:14 AM Gunnar Hellström <
[email-masked]> wrote:

> [email-masked]
>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 10 Feb 2021 20:34:26 +0100

I made the changes to reduce the nits errors and comments.

A new nits warning appeared:

   == There is 1 instance of lines with non-ascii characters in the document.

This refers to the reference of the new RFC 8865, where I was offered to 
spell my last name properly "Hellström" in the author element.

    [RFC8865]  Holmberg, C. and G. Hellström, "T.140 Real-Time Text
               Conversation over WebRTC Data Channels", RFC 8865,
               DOI 10.17487/RFC8865, January 2021,
               <https://www.rfc-editor.org/info/rfc8865>.

I assume that this is manageable, so I intend to submit.

Gunnar

Den 2021-02-10 kl. 18:37, skrev Bernard Aboba:
> On Wed, Feb 10, 2021 at 8:14 AM Gunnar Hellström 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Bernard,
>
>     However, one warning was because the nits check found what looks
>     like a reference in brackets, but is part of a symbolic screen
>     picture example containing a source label for text in brackets.
>
>     This was the warning:
>
>     Regarding the comment about pre-RFC5378 work, I have the required
>     grants to the BCP78 rights.
>
>     Thanks,
>
>     Gunnar
>
>
>>     Just ran IDnits on the document and got an error (see below). 
>>     Can you fix the issues and resubmit the document?
>>     idnits 2.16.05
>>
>>
>>     -- 
>>     Gunnar Hellström
>>     GHAccess

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 10 Feb 2021 21:36:17 +0100

I submitted version -13,  .xml and .txt, but needed first to hand-edit 
the .txt file to replace ö with o to get it accepted.

I am afraid the reference xml for RFC 8865 needs to be changed to ASCII 
and eventually the nits and submission tools modified to accept 
non-ascii where it is allowed.

I will report to the tools group.

Gunnar

Den 2021-02-10 kl. 20:34, skrev Gunnar Hellström:
>   Checking nits according tohttps://www.ietf.org/id-info/1id-guidelines.txt:
> This refers to the reference of the new RFC 8865, where I was offered 
> to spell my last name properly "Hellström" in the author element.
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Feb 2021 00:29:24 +0100

Folks, the purpose of draft writing is not to placate idnits, but to get work done.

Changing [] into () just to get one idnits warning less strikes me as borderline.

Asking for a name to be mangled (o for ö) because idnits is pointing out the ö just in case, is no longer borderline…
No, the reference xml is exactly right, and nothing should be changed here.

Please simply ignore warnings that are irrelevant/false positives.
An updated idnits is coming soon...

Apologies for this public service message.

Grüße, Carsten

> On 2021-02-10, at 21:36, Gunnar Hellström <[email-masked]> wrote:
> 
> I submitted version -13,  .xml and .txt, but needed first to hand-edit the .txt file to replace ö with o to get it accepted. 
> 
> I am afraid the reference xml for RFC 8865 needs to be changed to ASCII and eventually the nits and submission tools modified to accept non-ascii where it is allowed.
> 
>> This refers to the reference of the new RFC 8865, where I was offered to spell my last name properly "Hellström" in the author element.
>> 
>>> On Wed, Feb 10, 2021 at 8:14 AM Gunnar Hellström <[email-masked]>             wrote:
>>> Bernard,
>>> 
>>> However, one warning was because the nits check found what looks like a reference in brackets, but is part of a symbolic screen picture example containing a source label for text in brackets. 
>>> 
>>> This was the warning:
>>> 
>>> Regarding the comment about pre-RFC5378 work, I have the required grants to the BCP78 rights. 
>>> 
>>> Thanks,
>>> 
>>> Gunnar
>>> 
>>> 
>>> 
>>>> Just ran IDnits on the document and got an error (see below).  Can you fix the issues and resubmit the document? 
>>>> idnits 2.16.05 
>>>> 
>>>> 
>>>> -- 
>>>> Gunnar Hellström
>>>> GHAccess
>>>> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 11 Feb 2021 07:53:04 +0100

Carsten,

Yes, the allowed "ö" in the author name in a reference was not borderline.

I tried with ignoring the idnits warning. But then the submission tool 
refused to submit. I gave it both the .xml and the .txt files. Maybe it 
would have been accepted if I only provided the .xml ?  Will the 
submission tool also be updated soon to support and guide submission of 
files with non-ascii?

For me, I could very well continue to use "Hellstrom" as my IETF name 
but was offered to use "Hellström" as full name in RFC 8865 and thereby 
in its reference. Now I do not want that to cause submission problems if 
we are in a transition phase to a non-ascii world.

Apologies for continuing on this non-avtcore topic here. We should move 
to a more suitable group.

Thanks,

Gunnar

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Feb 2021 08:27:31 +0100

Reply-To set to tools-discuss.

On 2021-02-11, at 07:53, Gunnar Hellström <[email-masked]> wrote:
> I tried with ignoring the idnits warning. But then the submission tool refused to submit.

Did it give an error message?  The clue may be in there.

> I gave it both the .xml and the .txt files. Maybe it would have been accepted if I only provided the .xml ?  

That is generally now what you want to do, indeed.
You may want to convert it into RFCXMLv3 as well in order to get proper HTML output;

  xml2rfc --v2v3 my-draft.xml

…gives you an my-draft.v2v3.xml that you can submit.
The submission page does not currently go to the length of revealing this (or anything else you need to know to submit in an RFCXMLv3 world).

> Will the submission tool also be updated soon to support and guide submission of files with non-ascii?

It sure already supports beyond-ASCII input in those cases where RFC 7997 allows it, and author names (as well as figures) are among those.

> For me, I could very well continue to use "Hellstrom" as my IETF name

But that is not your name.

> but was offered to use "Hellström" as full name in RFC 8865 and thereby in its reference. Now I do not want that to cause submission problems if we are in a transition phase to a non-ascii world.

Well, the reference is in that RFC.  That RFC will not be changed, so anybody referencing that RFC would have a problem if that were indeed a problem.
And 8899, 8893, 8790, ...

> Apologies for continuing on this non-avtcore topic here. We should move to a more suitable group.

(Please send any reply to tools-discuss and not avtcore.)

Grüße, Carsten