Re: [Gen-art] [Slim] Review of draft-ietf-slim-negotiating-human-language-06
no language in common. It is OPTIONAL for the callee to honor this preference. For example, a PSAP is likely to attempt the call even without an indicated preference when there is no language in common, while a call center might choose to fail the call. The mechanism for indicating this preference is that, in an offer, if the last character of any of the 'humintlang-recv' or 'humintlang- send' values is an asterisk, this indicates a request to not fail the call. The called party MAY ignore the indication, e.g., for the emergency services use case, regardless of the absence of an asterisk, a PSAP will likely not fail the call; some call centers might reject a call even with an asterisk. This still does not meet Dale's comment. Insert a sentence saying: "A preference for getting the call denied in case of no language match SHOULD be indicated by no asterisk appended on any humintlang attribute value in the whole SDP." 5.5. Examples Given that the combined audio/video mechanism is the only irregularity in this system, there ought to be an example of it. E.g., An example of a supplemental video stream with a spoken language audio stream: m=video 51372 RTP/AVP 31 32 a=humintlang-send:en a=humintlang-recv:en m=audio 49250 RTP/AVP 20 a=humintlang-send:en a=humintlang-recv:en If the video stream is supplemental then it doesn't have a language (the text that suggested otherwise has been deleted). But I am considering adding more examples. I provided a rich set of examples in my LC comments of Feb 13. Please consider them as a base even if some need revision if the proposed extended meaning of the asterisk is not accepted. 6. IANA Considerations humintlang-value = Language-Tag [ asterisk ] ; Language-Tag defined in RFC 5646 asterisk = "*" s/Language-Tag defined in RFC 5646/Language-Tag as defined in RFC 5646/ But perhaps also s/RFC 5646/BCP 47/, which ensures that "humintlang" tracks the current version of language tags. Ok. Appendix A. Historic Alternative Proposal: Caller-prefs This results in a more fragile solution since the media modality and language would be negotiated using SIP, and then the specific media formats (which inherently include the modality) would be negotiated at a different level (typically SDP, especially in the emergency calling cases), making it easier to have mismatches (such as where the media modality negotiated in SIP don't match what was negotiated using SDP). "the media modality and language would be negotiated using SIP" isn't quite the right way to say it because SIP isn't explicitly negotiating the modality. Better would be ... the language (and by implication the media modality) would be negotiated using SIP, and then the specific media (which inherently include the modalities and formats) would be negotiated at a different level ... This section has been deleted. Did we agree on that? [END] Regards Gunnar -- - Gunnar Hellström Omnitor gunnar.hellst...@omnitor.se +46 708 204 288 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [MMUSIC] Genart last call review of draft-ietf-mmusic-t140-usage-data-channel-11
Hi Linda, You ask below: "ITU-T T.140 uses RTP as transport, whereas this document describes using WebRTC for transport. WebRTC uses SRTP. Does it mean this document proposes a different transport mechanism as the ITU-T T140? Why?" ITU-T T.140 is a generally applicable presentation protocol for real-time text. Transports have been standardized for T.140 in a number of multimedia systems, most of them nowadays obsolete. E.g. ITU-T Q.224 for transport in H.320 ISDN Multimedia system, ITU-T V.18 for transport by low bitrate modems. etc. For use in traditional IP based multimedia systems ITU-T H.323 and IETF SIP, RTP transport is the standardized transport with packetization of T.140 specified in RFC 4103. When WewbRTC was specified it was early said that only audio and video would be transported by RTP. All other, including real-time text would use data channels. This decision was documented in use case U-C-5 in ietf-rtcweb-data-channel. The reviewed draft obeys that decision and specifies how the general T.140 transport is to be applied on a WebRTC data channel. Regards Gunnar Den 2020-02-14 kl. 17:50, skrev Linda Dunbar via Datatracker: > Reviewer: Linda Dunbar > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-mmusic-t140-usage-data-channel-11 > Reviewer: Linda Dunbar > Review Date: 2020-02-14 > IETF LC End Date: 2020-02-06 > IESG Telechat date: Not scheduled for a telechat > > Summary: > This document specifies how a WebRTC data channel can be used as a transport > mechanism for T.140. The document ties several other documents together, > like xxx can be used, yyy must be followed, etc.. So it is not easy to > validate the mechanism described by the document unless you are familiar > with > all the reference documents. > But in general, the document is very clear. > > Just one question: > ITU-T T.140 uses RTP as transport, whereas this document describes using > WebRTC > for transport. WebRTC uses SRTP. > > Does it mean this document proposes a different transport mechanism as the > ITU-T T140? Why? > > Major issues: None > > Minor issues: None > > Nits/editorial comments: > > Linda Dunbar > > _______ > mmusic mailing list > mmu...@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- + + + + + + + + + + + + + + Gunnar Hellström Omnitor gunnar.hellst...@omnitor.se +46 708 204 288 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [MMUSIC] Genart last call review of draft-ietf-mmusic-t140-usage-data-channel-11
Hi Linda, I get the impression that you did think of T.140 as a standardized combination of audio, video and real-time text. That combination is called "total conversation", a term first mentioned in ITU-T F.703 "Multimedia conversational services", and after that mentioned in various standards for various technical environments. T.140 can be thought of as a "text codec" for the real-time text media. It can be combined with an audio codec and a video codec, all with their specific but externally specified packetization and transport standards for each technical session environment. WebRTC is one, where audio and video are carried by SRTP and T.140 real-time text by the WebRTC data channel in the way specified by the t140-usage draft. A session can contain any combination of these three media, as well as other data channel types. Regards Gunnar Den 2020-02-14 kl. 23:16, skrev Christer Holmberg: Hi, >Yes, that is exactly what I was asking. > >Based on your answer, the second sentence of your page 2 should be: > >“ this document specifies how a WebRTC data channel is used as a transport for > the real time text of T140”. It is the "of T140" part that confuses me. T140 is ONLY for real-time text. There is no "T140 audio" or "T140 video". Regards, Christer Linda From: Christer Holmberg <mailto:christer.holmb...@ericsson.com> Sent: Friday, February 14, 2020 4:02 PM To: Linda Dunbar <mailto:linda.dun...@futurewei..com>; Gunnar Hellström <mailto:gunnar.hellst...@omnitor.se>; gen-art@ietf.org<mailto:gen-art@ietf.org> Cc: last-c...@ietf.org<mailto:last-c...@ietf.org>; mmu...@ietf.org<mailto:mmu...@ietf.org>; draft-ietf-mmusic-t140-usage-data-channel@ietf.org<mailto:draft-ietf-mmusic-t140-usage-data-channel@ietf.org> Subject: Re: [MMUSIC] Genart last call review of draft-ietf-mmusic-t140-usage-data-channel-11 Hi Linda, >Gunnar, I am not Gunnar, but I will reply :) >Thank you very much for the explanation. > >Do you mean WebRTC data channel is used as Transport mechanism for real-time >text, >but Audio and Video of T140 still use RTP or SRTP? I am not sure what you mean by "Audio and Video of T140". In WebRTC Audio and Video use SRTP, while the T.140 real-time text uses the data channel. Regards, Christer -Original Message- From: Gunnar Hellström mailto:gunnar.hellst...@omnitor.se>> Sent: Friday, February 14, 2020 1:03 PM To: Linda Dunbar mailto:linda.dun...@futurewei.com>>; gen-art@ietf.org<mailto:gen-art@ietf.org> Cc: last-c...@ietf.org<mailto:last-c...@ietf.org>; mmu...@ietf.org<mailto:mmu...@ietf.org>; draft-ietf-mmusic-t140-usage-data-channel@ietf.org<mailto:draft-ietf-mmusic-t140-usage-data-channel@ietf.org> Subject: Re: [MMUSIC] Genart last call review of draft-ietf-mmusic-t140-usage-data-channel-11 Hi Linda, You ask below: "ITU-T T.140 uses RTP as transport, whereas this document describes using WebRTC for transport. WebRTC uses SRTP. Does it mean this document proposes a different transport mechanism as the ITU-T T140? Why?" ITU-T T.140 is a generally applicable presentation protocol for real-time text. Transports have been standardized for T.140 in a number of multimedia systems, most of them nowadays obsolete. E.g. ITU-T Q.224 for transport in H.320 ISDN Multimedia system, ITU-T V.18 for transport by low bitrate modems. etc. For use in traditional IP based multimedia systems ITU-T H.323 and IETF SIP, RTP transport is the standardized transport with packetization of T.140 specified in RFC 4103. When WewbRTC was specified it was early said that only audio and video would be transported by RTP. All other, including real-time text would use data channels. This decision was documented in use case U-C-5 in ietf-rtcweb-data-channel. The reviewed draft obeys that decision and specifies how the general T.140 transport is to be applied on a WebRTC data channel. Regards Gunnar Den 2020-02-14 kl. 17:50, skrev Linda Dunbar via Datatracker: > Reviewer: Linda Dunbar > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed by > the IESG for the IETF Chair. Please treat these comments just like > any other last call comments. > > For more information, please see the FAQ at > > <https://protect2.fireeye.com/v1/url?k=7e8050ab-220a727d-7e801030-0cc47ad93dcc-e1706ed98975c910=1=4dbf2e13-f320-470a-a001-dcb3aa68c975=https%3A%2F%2Fnam03.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Ftrac..ietf.org%252Ftrac%252Fgen%252Fwiki%252FGenArtfaq%26amp%3Bdata%3D02%257C01%257Clinda.dunbar%2540futurewei.com%257C0c2dca83131747ea654c08d7b18089ee%257C0fee8ff2a3b2401
Re: [Gen-art] Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14
e quite similar to the security aspects on the elements specified in RFC 4575. Its security aspects are specified in https://tools.ietf.org/html/rfc4575#section-8 You are right that that example contains mainly SHOULD and RECOMMENDED and no SHALL. I suggest changing: "Integrity considerations SHALL be taken when composing the label." to: "Information available to the mixer for composing the label may contain sensitive personal information that SHOULD not be revealed in sessions not securely authenticated and protected. Integrity considerations regarding how much personal information is included in the label SHOULD therefore be taken when composing the label." Page 33, 3rd paragraph, 1st sentence: any reason for the change from “T.140” in the previous and following paragraphs to “t140” in this one? [GH] No, they should be "T.140 data channels" for all cases in that paragraph. I have changed. Page 33, 6th paragraph: how is disappearance determined? [GH]The disappearance may be signaled by the SIP conference system RFC 4353, RFC 4575 etc. as a conference notification if that system is used, or simply by removal of the text media in an RTP session modification. There may also be a malfunction detected by keep-alive transactions not being maintained. I suggest to not detail how it disappears. Page 35, section 11, 3rd paragraph, 2nd sentence before creating a new sentence (see nits, below): I’m having troubles tying the adjective “secure” to each of the nouns in the sentence. It works for “signaling” and perhaps “media”, but for “authentication”, one sort of assumes that authentication mechanism is secure and helping to provide the security. Perhaps you could reword that sentence? [GH] I propose to change the sentence from: "Counteractions should be to require secure signaling, media and authentication, and to provide higher level conference functions e.g. for blocking and expelling participants." to: "Counteractions should be to require authentication, secure session signaling and secure media. Higher level conference functions should also be used e.g., for blocking and expelling participants who caused security concerns." Thanks, Gunnar Hellstrom -- Gunnar Hellström GHAccess gunnar.hellst...@ghaccess.se ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14
int: insert “the” before “next”. Change “if even” to “even if”. Insert “a” between “for” and “word delimiter”. Page 28, section 4.2.4, 1st paragraph: insert “the” before “UTF-8”. Change “transform” to “transformation”. [GH] "Encoding" used instead. It seems commonly used. Page 28, section 4.2.4, “BEL”: change the comma after “session” to a period. Capitalize “provides”. Page 28, section 4.2.4, “NEW LINE”, 3rd sentence: insert “the” before “display”. Page 28, section 4.2.4, “CR LF”, 1st sentence: delete the comma after “supported”. Page 28, section 4.2.4, “CR LF”, 3rd sentence: insert “the” before “display”. Page 28, section 4.2.4, “INT ESC”, 1st sentence: insert “the” before “mode”. Page 28, section 4.2.4, “SGR”, 2nd sentence: insert “the” before “rendition”. Page 29, 1st partial sentence: insert a hyphen between “256” and “bytes”. Then change “bytes” to “byte”. Page 29, “BOM”, 1st sentence: insert “it” before “SHALL”. [GH] Accepted, but part of the first statement is separated out to a sentence of its own: " It SHALL be deleted from incoming streams." Page 29, “Missing text mark”, 1st sentence: change the comma after “apostrophe ‘” to a period. Insert “It” before “marks”. Insert “the” before “place”. Insert “the” before “stream”. Page 29, “SGR”, 1st sentence: delete the comma after “(SGR)”. Insert “the” before “status”. Page 29, “SGR”, 2nd sentence: change “originated” to “originating”. Page 29, BS, last sentence: change “not” to “be”. Page 32, section 6.1, title: drop the “e.g.” in the subsection title. [GH] Not done. Many countries have their own terms for textphones. In USA and a few other countries (Canada, Australia) they are called TTY. That term is not understood in other countries. "Textphone" may not be understood in USA. Therefore I prefer having both the general term and the (e.g., TTYs) in the heading. Page 32, section 6.1, 2nd paragraph, parenthetical: perhaps you want “i.e.,” instead of “e.g.” here given that further down you put “TTYS” in another parenthetical as though it weren’t just an example but the only exemplar of this type of device under discussion. [GH] No. I did not mean "i.e.,". "TTY" is just one example with specific technology. So, I suggest to keep this sentence: "One case that may occur is a gateway to PSTN for communication with textphones (e.g., TTYs)." While in the other places where (TTY) was mentioned it is deleted with its parenthesis. Page 32, section 6.1, 2nd paragraph, last sentence: delete “make”. Change “adaptions” to “adapt”. Delete “for” before “the functional”. Delete “(TTY)”. [GH] I also needed to insert "to" before "adapt" to make: "This solution makes it possible to adapt to the functional limitations of the textphone." Page 32, section 6.1, 3rd paragraph: delete “(TTYs)”. Page 33, 2nd paragraph, 2nd sentence: insert “a” before “two-way”. Page 33, 3rd paragraph, 2nd sentence: insert “the” before “NAME”. Page 33, section 7: insert a hyphen between “multiparty” and “mixing” in this one instance of that term. Other uses of the term in the document should not be hyphenated. Page 34, section 8, 1st paragraph: I like the sound of the sentence better if you swap “valid” and “also”. That’s just me. [GH] Accepted so that you will like to read it again. Page 34, section 8, 3rd paragraph, 1st sentence: insert a space between “second” and “(“CPS”)”. Page 34, section 8, 3rd paragraph, 3rd sentence: insert “an” before “RTP”. Regarding “excess”: in excess of what? Page 35, section 11, 1st paragraph, 1st sentence: append a comma after “pack”. Page 35, section 11, 2nd paragraph, 1st sentence: append a comma after “CNAME”. Page 35, section 11, 3rd paragraph, 1st sentence: I suggest inserting “emitting” before “a continuous”. Change the comma after “flow of text” to a period. Delete the following “or”. Change the rest of that sentence to read something like: “They may also send text that appears to originate from other participants.” I rewrote that because the malicious participants don’t themselves masquerade as text, although that might be a mildly amusing Halloween costume. Page 35, section 11, 4th paragraph: delete one of “section” or “Section”. You capitalize that term interchangeably, so it’s your choice. Page 35, section 12.1 (when discussing -14 only): change “Cucherawy” to “Kucherawy” unless we’re talking about someone else. Yeah, I know these will all be deleted upon publication, but it caught my eye. I have not reviewed the remainder of the change history entries. Thanks again for the thorough review. I have next version ready, also including changed caused by security comments and discussed in other mail. Do you want me to submit the new version. Regards Gunnar -- Gunnar Hellström GHAccess gunnar.hellst...@ghaccess.se ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14
Peter,
I have made the extra few adjustments you proposed.
For the use of "disappeared", I agree that it is an unusual term in this
context.
I checked RFC 4575, and there it is said that users "depart" or
"disconnect" from a conference. "Disconnect" feels most familiar, so I
propose to change the sentence to:
"When a participant on the RTP side is disconnected from the multiparty
session, the corresponding T.140 data channel(s) SHOULD be closed."
Thanks,
Gunnar
--
Gunnar Hellström
GHAccess
gunnar.hellst...@ghaccess.se <mailto:gunnar.hellst...@ghaccess.se>
Den 2021-05-07 kl. 20:55, skrev Peter Yee:
Thanks for the quick response, Gunnar. I've prefaced my replies below with
[PEY].
-Peter
-Original Message-
From: Gunnar Hellström [mailto:gunnar.hellst...@ghaccess.se]
Sent: Thursday, May 06, 2021 2:14 PM
To: Peter Yee; gen-art@ietf.org
Cc: a...@ietf.org; draft-ietf-avtcore-multi-party-rtt-mix@ietf.org;
last-c...@ietf.org
Subject: Re: Genart last call review of
draft-ietf-avtcore-multi-party-rtt-mix-14
Thank you for the thorough review. Please see comments inline.
I will split the answers, and start here with answers and change
proposals for the minor issues:
Den 2021-05-06 kl. 05:41, skrev Peter Yee via Datatracker:
Reviewer: Peter Yee
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-avtcore-multi-party-rtt-mix-14
Reviewer: Peter Yee
Review Date: 2021-05-05
IETF LC End Date: 2021-05-03
IESG Telechat date: Not scheduled for a telechat
Summary: This draft specifies updates to RFC 4103 to allow real-time text
mixing for both multiparty-aware and multiparty-unaware participants. It has
some minor issues that should be addressed before publication. [Ready with
issues]
Major issues: None
Minor issues:
Page 7, 1st block, 13th sentence: what constitutes a “reasonable effort”? It
might be best to drop this sentence.
[GH] This reason is important for the desicion on technology selection.
I suggest a change from:
"For best deployment opportunity, it should be possible to upgrade
existing endpoint solutions to be multi-party aware with a reasonable
effort."
to
"For best deployment opportunity, it should be feasible to upgrade
existing endpoint solutions to become multiparty-aware."
[PEY] I'm fine with that.
Page 7, 2nd block, 2nd sentence, “300 ms”: would it make sense to append
“period” or “timeout” after this value?
[GH] I suggest to change from "every 300 ms." to "with 300 ms intervals."
[PEY] Works for me.
Page 13, section 3.4, 2nd paragraph, 1st sentence: in regards to “only part”,
how is this calculated?
[GH] I suggest to change from "If the "CPS" value is reached, longer
transmission intervals SHALL be applied and only part of the text queued
for transmission sent at end of each transmission interval, until the
transmission rate falls under the "CPS" value again."
to
"If the "CPS" value is reached, longer transmission intervals SHALL be
applied and only as much of the text queued for transmission sent at end
of each transmission interval that can be allowed without exceeding the
"CPS" value, until the transmission rate falls under the "CPS" value
again. Division of text for partial transmission MUST then be made at
T140block borders. "
[PEY] That's clearer. I'd insert "the" before "end".
Page 15, section 3.12, 2nd paragraph, 1st sentence: The placing of all
available redundant levels in the packet is presumably subject to a maximum
packet size or the “CPS” limit, if there are obnoxious levels of redundancy
specified?
[GH] Thanks, a good observation. It is already covered in section 3.10,
but it could be more emphasized there. In 3.12 we are only dealing with
the redundancy, which must be possible to send and is not included in
the "CPS" value.
I suggest that the following part of 3.10 is improved from:
"Redundant text SHALL also be included. See Section 3.12"
to;
"Redundant text SHALL also be included, and the assessment of how much
new text can be included within the maximum packet size MUST take into
account that the redundancy has priority to be transmitted in its
entirety. See Section 3.12."
[PEY] That works.
Page 17, section 3.17.2, 4th paragraph, 2nd sentence: “SHALL prefer” seems odd.
It doesn’t say that the marking will actually be done. It’s just preferred. If
you’re not going to require the marking in that sentence, then perhaps change
“SHALL” to “SHOULD”.
[
Re: [Gen-art] Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14
Version -17 of the draft is submitted, with intention to have all Genart and Secdir review comments resolved. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-17.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-17 Regards Gunnar -- Gunnar Hellström GHAccess gunnar.hellst...@ghaccess.se Den 2021-05-07 kl. 21:14, skrev Peter Yee: Responses prefixed with [PEY] below. Kind regards, -Peter -Original Message- From: Gunnar Hellström [mailto:gunnar.hellst...@ghaccess.se] Sent: Friday, May 07, 2021 11:36 AM To: Peter Yee; gen-art@ietf.org Cc: a...@ietf.org; draft-ietf-avtcore-multi-party-rtt-mix@ietf.org; last-c...@ietf.org Subject: Re: Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14 Continuing with comments and edit proposals from "Nits/editorial comments:" below. Den 2021-05-06 kl. 05:41, skrev Peter Yee via Datatracker: Reviewer: Peter Yee Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-avtcore-multi-party-rtt-mix-14 Reviewer: Peter Yee Review Date: 2021-05-05 IETF LC End Date: 2021-05-03 IESG Telechat date: Not scheduled for a telechat Summary: This draft specifies updates to RFC 4103 to allow real-time text mixing for both multiparty-aware and multiparty-unaware participants. It has some minor issues that should be addressed before publication. [Ready with issues] Nits/editorial comments: Change “multiparty capable” to “multiparty-capable” throughout the document. [GH] I suggest to change to "multiparty-aware" instead for consistency. [PEY] Fine by me. Page 6, section 1.1, 2nd paragraph: insert “are” before “as”. [GH] Recently changed to just "are defined in" by proposal in another review. I suggest to keep that. [PEY] Agreed. Page 6, “multiparty-unaware”: change “stands for” to “describes”. [GH] Accepted and done.Your use of hyphen in "multiparty-unaware" made me understand that that term also should be hyphenated all through the document. Done. [PEY] Yes, I failed to include that hyphenation in the general nits although I marked all of them in my review copy. Page 29, “BOM”, 1st sentence: insert “it” before “SHALL”. [GH] Accepted, but part of the first statement is separated out to a sentence of its own: " It SHALL be deleted from incoming streams." [PEY] That's fine. I didn't fuss so much over sentence structure for the definitions. Page 32, section 6.1, title: drop the “e.g.” in the subsection title. [GH] Not done. Many countries have their own terms for textphones. In USA and a few other countries (Canada, Australia) they are called TTY. That term is not understood in other countries. "Textphone" may not be understood in USA. Therefore I prefer having both the general term and the (e.g., TTYs) in the heading. [PEY] With that understanding, I'm fine leaving an examples or two in the body text. As a matter of style, I don't think examples should appear in the title, but I won't argue the point. It's only style. :-) Page 32, section 6.1, 2nd paragraph, parenthetical: perhaps you want “i.e.,” instead of “e.g.” here given that further down you put “TTYS” in another parenthetical as though it weren’t just an example but the only exemplar of this type of device under discussion. [GH] No. I did not mean "i.e.,". "TTY" is just one example with specific technology. So, I suggest to keep this sentence:"One case that may occur is a gateway to PSTN for communication with textphones (e.g., TTYs)." While in the other places where (TTY) was mentioned it is deleted with its parenthesis. [PEY] Okay. Page 32, section 6.1, 2nd paragraph, last sentence: delete “make”. Change “adaptions” to “adapt”. Delete “for” before “the functional”. Delete “(TTY)”. [GH] I also needed to insert "to" before "adapt" to make: "This solution makes it possible to adapt to the functional limitations of the textphone." [PEY] I'm fine with the that sentence. Thanks again for the thorough review. I have next version ready, also including changed caused by security comments and discussed in other mail. Do you want me to submit the new version. [PEY] If you have no further changes pending from other reviews, it probably makes sense to submit a new version with everything incorporated. I admit that I didn
