Subject: RE: [Enum] Comment on draft-ietf-enum-voice-01.txt about callsneeding text capability

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Wed, 2 Nov 2005 17:24:02 -0500

Let me break silence over naming ...

Inline [RRR]

Name "rtxt" "text" "voicetext" vortex" "txp" "votext" ?

-------------------------------------------------------

Please help to assign a name for the service! In an offline discussion we

were close to assigning "rtxt" or "text" to it when we hesitated because it

may be good to show its voice capabilities as well in the name.

[RRR] Let us use the term "rtxt."

[RRR] We cannot use the term "Text."  "Text" as an application can be non-real-time - also, SIP or RTP does NOT recognize "text" as a real-time application. If needed, we may also contact SIP, SIPPING, MMUSIC, and AVT WG. Any real-time media that needs to be sent over RTP is the right one to standardize it.

[RRR] I have seen that TEXT as a media is sent over TCP (not over RTP/UDP). If AVT WG recognizes that TEXT is also sent over TCP, and it is not a real-time application, the naming of this as TEXT will be confusing among the standards. So, if ENUM decides to name it as "text," it is then needs to take approval from AVT and other WGs of IETF.

[RRR] Even if we decide "rtxt" or other (excluding TEXT) name, we still need to inform AVT and other WGs about our naming decision. In this way, it will be confirmed as standard across the whole IETF.

As soon as we have a proposed name, I can submit a draft proposing

registering it as an enumservice for the scheme "tel".

Regards

Gunnar

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Fri, 4 Nov 2005 06:55:00 +0100

RE: [Enum] Comment on draft-ietf-enum-voice-01.txt about callsneeding text
capabilityRadhika,
After some consideration, I am back to proposing that we book the
enumservice name "text" to mean real time conversational text with optional
voice.

From the discussion here in the enum group I realized that we can specify
voice+text to indicate capability for both, like this.

$ORIGIN 0.0.0.0.6.9.4.1.4.1.4.4.e164.arpa.
. IN NAPTR 100 10 "u" "E2U+voice:tel+text:tel" "!^.*$!tel:

+447700900000!" .

Thereby my fear that people would not understand that the "text" service
also can carry voice was reduced. It also can show that the same terminal
can be used for both services. So if you want to call a plain voice call,
you may find "voice" in the record, use it and do not need to understand
alternatives.

I have also understood that a readable and understandable name is to be
strongly preferred.

I also saw that various message-wise text services have booked their names
already ( email, fax, sms, ems, mms ), so I realized that there should be
very little confusion. ( I have not seen any booking for IM based text
messaging though, it would be interesting to know if they intend to book a
name. )

The multimedia framework service specification F.700 describes the "text"
medium. It gives characteristics for various forms of text, with real time
ones and non-real time ones. So that standard definition of the text medium
at least includes real time and is not as non-real-timish as you want to see
text.

Another example: In the MIME media type specification, there is a media type
called "text". It contains various subtypes that can be used for real time
and non-real-time.

In real life, there are all time relations conected to text as well as voice
and video. I can buy a video cassette. I can buy a voice recording on
casette. I can watch TV with real time subtitled text.

We do not need to go into transport protocol discussion on use of RTP or
TCP. It is the human experience of real time that we want to achieve. We
need to meet the user requirement of not more than one second from character
entry to display for good quality of service. Two seconds for usable level.
We have standardised to use RTP, and agree on it for use in IP. But it is
possible to use TCP for similar user experience. We hope to maintain the
implemented base harmonized. However, most of the terminals specified by the
enumservice  "text" will be PSTN terminals using modem transport outside the
gateway. For SIP terminals we are not supposed to use the detailed
specifications on the enum level.

So, that was why I want a readable name and see "text" as the currently best
alternative very well matching "voice" and "video" for use in real time
calls.

Gunnar

----------------------------------------------------------------------------
-
Gunnar Hellström, Omnitor
[email-masked]
Mob: +46 708 204 288
Phone: +46 8 556 002 03
www.omnitor.se
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
Roy, Radhika (AEAD)
  Sent: Wednesday, November 02, 2005 11:24 PM
  To: Gunnar Hellstrom; lconroy
  Cc: [email-masked]
  Subject: RE: [Enum] Comment on draft-ietf-enum-voice-01.txt about
callsneedingtext capability

  Inline [RRR]

  were close to assigning "rtxt" or "text" to it when we hesitated because
it

  [RRR] Let us use the term “rtxt.”

  [RRR] We cannot use the term “Text.”  “Text” as an application can be
non-real-time – also, SIP or RTP does NOT recognize “text” as a real-time
application. If needed, we may also contact SIP, SIPPING, MMUSIC, and AVT
WG. Any real-time media that needs to be sent over RTP is the right one to
standardize it.

  [RRR] I have seen that TEXT as a media is sent over TCP (not over
RTP/UDP). If AVT WG recognizes that TEXT is also sent over TCP, and it is
not a real-time application, the naming of this as TEXT will be confusing
among the standards. So, if ENUM decides to name it as "text," it is then
needs to take approval from AVT and other WGs of IETF.

  [RRR] Even if we decide "rtxt" or other (excluding TEXT) name, we still
need to inform AVT and other WGs about our naming decision. In this way, it
will be confirmed as standard across the whole IETF.

  Regards

  Gunnar