RTP Payload for Text Conversation
draft-ietf-avt-rfc2793bis-09

IANA Last Call Comments:
Upon approval of this document the IANA will update the
references for 2 registered parameters:

t140 RTP Payload Format MIME types at the following:


text/t140 MIME Media type at the following:

[Ballot comment]
I see mixed use of "T140block" and "T.140block"
Are they not the same? If so, maybe a consistent notation
would be better. Same for "T140" and "T.140"

*** matchref -- match citations and references.
    Input file: draft-ietf-avt-rfc2793bis-09.txt

!! Missing citation for Normative reference:
  P017 L056:    [12] Postel, J.,"Internet Protocol", RFC 791, 1981.

!! Missing citation for Informative reference:
  P018 L015:    [15] Schulzrinne, H., Petrack, S., "RTP Payload for DTMF Digits,

[Ballot comment]
*** matchref -- match citations and references.
    Input file: draft-ietf-avt-rfc2793bis-09.txt

!! Missing citation for Normative reference:
  P017 L056:    [12] Postel, J.,"Internet Protocol", RFC 791, 1981.

!! Missing citation for Informative reference:
  P018 L015:    [15] Schulzrinne, H., Petrack, S., "RTP Payload for DTMF Digits,

[Ballot comment]
Reviewed by Michael Patton, Gen-ART

His review:

Summary: This draft is basically ready for publication as Proposed
Standard, but has nits that should be fixed before
publication.  All of these are in the xcope of what can be
done in RFC final prep.
----------------------------------------------------------------

While reference [14] is not required to understand the protocol
itself, it's important to the understanding of the "Security
Considerations" and I therefore think that it should be Normative.


[This next one is really almost just a typo, but the one word change
actually changes the meaning, so I put it up front.  I think this is
actually the point the authors are trying to make, since the original
wording seems a non-sequitur to me.]

In the third paragraph of Section 9 is the phrase "this application
will experience very high packet loss rates before it needs to perform
any reduction in the sending rate."  I believe the authors mean that
the application works fine even in the face of large loss rates, but
that's not actually what their chosen words mean, the actual words
imply that something will cause the application to experience higher
loss.  If that's really the intent, I believe that can be fixed by
simply changing the word "will" to "can".  If they meant something
else, more extensive rewording is needed.


Typos
-----

Section 1: "in connection to" => "in connection with"

Section 3.1: "are depending on" => "are dependent on"

[Ballot discuss]
Section 3.3 says:
  >
  > Any composite character sequence (CCS) SHOULD be placed
  > within one block.
  >
  Splitting a CCS across blocks seems like it adds complexity.
  Is there a reason that this SHOULD is not a MUST?

[Ballot comment]
Two-week MIME type review period for text/t140 ends on 2 December.  Please confirm that no issues are identified (none have been raised so far).

[Note]: 'text/red is in revision to be text payload types only
RFC Editor Note will change IANA Considerations to note text/t140 is an update, not new' added by Allison Mankin

[Note]: 'ETSI want to publish their own copy of this RFC in/by April - need to discuss this with I* - see log
text/red in revision to be text payload types only
RFC Editor Note in this in IANA Considerations to note registration is an update, not new (oversight
not to change the text)' added by Allison Mankin

Cisco IPR claim is known to the chairs and WG.
Corresponded with editor Hellstrom:

2004-10-21
I have got a request from ETSI to prepare for ETSI endorsement of RFC2793bis when
published. In order to be able to endorse it, ETSI needs a letter from IETF saying that
IETF accepts the endorsement. Can you please guide me in that process. Can you take the
task on you to create that letter?

More explanation (same day):

But the request was not for IETF to endorse rfc2793bis. It was only for IETF to accept
that ETSI endorses RFC 2793bis.

Endorsing by ETSI will mean that an ETSI standard is created that gets the same title as
the RFC and just says that it is the RFC.

In some circumstances it is still important to have European standards.

I am part of a task force within ETSI, called STF 267, making a Guideline document for
mainstreamed real time text conversation. It is for this work that it is regarded
important to have ETSI endorse RFC 2793bis.

More explanations will come in the letter from ETSI.

And more:

There is no big rush. But there is also a process to be initiated and followed on the ETSI
side, so we want to initiate that now, and plan the steps to take. The final actions may
be as late as April, when the RFC is definitely needed.

gunnar.hellstrom@omnitor.se
stf267@etsi.org

[Note]: 'ETSI want to publish their own copy of this RFC in/by April - need to discuss this with I* - see log' added by Allison Mankin