Subject: [Slim] Translation Quality or type

From: Nik Tomkinson <[email-masked]>
Date: Thu, 2 Jul 2015 23:09:30 +0100

All,

in the November IETF last year, there was a suggestion from one participant
(Stéphane Bortzmeyer) about including some identification of translation
quality.

The question is at:
https://www.ietf.org/audio/ietf91/ietf91-coral2-20141110-0900-am1.mp3

move ahead to 1h 56m 00s (you may need to download it first).

The reason for this is principally because a lot of internet sites are
written in English and anyone who choses a non-english language as their
preferred language for the internet often receives bad machine-translated
pages. He suggests that with an indication of the type
(original/translation) and the translation quality (human/machine) then a
much better selection of translation can be made. We have this opportunity
now for multilingual email to avoid the mistake that multilingual internet
has made.

To accommodate this, I am just about to add this new field to the I-D for
Multipart-multilingual email:

translation-type := type-token
type-token := "original" / "human" / "automated"

so for example:

Translation-Type: original

Translation-Type: human

This would be for each language translation, so that 'original' is
untranslated content, 'human' is human-translated content and 'automated'
is machine-translated content. Obviously there is trust on the part of the
sender to properly classify the origin, but that is unavoidable.

Please let me know what you think, but bear in mind that the cut-off date
for I-D updates before Prague is 06-July 23:59 UTC so we have to be quick
to get this discussed and agreed by then. The current I-D version has
expired and I am keen to get a non-expired version available for people to
discuss in Prague.

Thanks in advance,

Nik.

-- 

-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:

<http://datatracker.ietf.org/doc/draft-tomkinson-multilangcontent/>
http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 3 Jul 2015 08:49:08 +0200

On Thu, Jul 02, 2015 at 11:09:30PM +0100,
 Nik Tomkinson <[email-masked]> wrote 

> type-token := "original" / "human" / "automated"

In many IETF working groups, when there is such a proposal, there is a
big discussion between the registryfull and the registryless
people. The first ones say there must be an authoritative list of
values (in the RFC or, better because more evolving, in an IANA
registry) so we can be sure of the interpretation of values. The
second ones say we can never capture all the nuances and subtleties of
the world in a fixed list.

Here, I am not sure that the only meaningful distinction is between
"human" and "automated". Some humans do a very poor job, too. One
could suggest:

type-token := "original" / "professional-human" / "amateur-human" /
"automated-first-generation" / "automated-artificial-intelligence" /
"automated-the-robot-in-hollywood-movies"

Or decide that it will be too complicated and we should instead
accept:

> type-token := "original" / <free text>

Toughts?

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 03 Jul 2015 10:46:37 +0200

I see some value of this kind of parameter also for the real-time case.
The time is here when it can be possible in some situations to select 
between using a low-cost automatic speech-to-text generation and a 
higher cost captioned telephony or text-relay service (higher cost for 
someone, not always the end-user).

But I agree that it is very hard to set good understandable values on a 
parameter expressing the type or quality of this kind of service.

Gunnar

Stephane Bortzmeyer skrev den 2015-07-03 08:49:
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

---

From: Nik Tomkinson <[email-masked]>
Date: Fri, 3 Jul 2015 16:29:55 +0100

Thanks for the responses.

To deal with the issue with having only original/human/automated, what
about the following?:

translation-type := type-token[ ";" "q" "=" qvalue ]
type-token :="human" / "automated"

where qvalue is a value between 0 and 1 with a default of 0.5 if missing

for example:

Translation-Type: human;q=0.8
Translation-Type: automated;q=0.4
Translation-Type: human

The Translation-Type SHOULD NOT appear in the original (untranslated) part
but it SHOULD appear in translated content.

Having this missing from the original text helps identify which is the
source to be translated into further languages if the user mail client
allows.

This enables us to dispose of the 'original' value which didn't lend itself
well to being graded on quality.

The qvalue can be set by the sender or provided by the translation service.

The draft suggests that:

"Additionally, interactive implementations MAY offer the user a choice from
among the available languages." so the qvalue may not need to be
bulletproof.

Comments?

Nik.

On 3 July 2015 at 09:46, Gunnar Hellström <[email-masked]>
wrote:

> between using a low-cost automatic speech-to-text generation and a higher
> cost captioned telephony or text-relay service (higher cost for someone,
> not always the end-user).
>

--

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Jul 2015 12:00:04 -0400

> parameter expressing the type or quality of this kind of service.

Yes. It is my understanding (2nd hand) there there are subjective 
decisions (preferences) when choosing a translation service.

While I can see how having a rating attached might be conceptually 
appealing, it is hard to imagine how it would be deployed in a way that 
is useful. And it seems likely to be subject to endless haggling.

Seems like a rat hole.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Sat, 4 Jul 2015 18:49:38 -0700

My recollection is that this was discussed in 
email prior to Dallas, but that's not important.

I am a strong proponent of keeping things as 
simple as possible, provided there is a way to 
extend them if experience shows that it is 
needed.  So, I think we should stick with the 
original suggestion of three values ("original", 
"human", "automated").  This is simple enough to 
be implementable and functional enough to be 
useful in providing a hint that may help the 
client choose the best version for the user.  If 
we try and capture the various nuances of quality 
we will end up with a very complex mechanism that 
is unlikely to be any more useful in real life. 
Let's go with the simple approach now.  If, after 
some deployment experience we realize that we 
really do need extra complexity, we can extend 
the mechanism then.

At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote:

>  To deal with the issue with having only 
> original/human/automated, what about the 
> following?:
>
>
>  The Translation-Type SHOULD NOT appear in the 
> original (untranslated) part but it SHOULD 
> appear in translated content.
>
>  Having this missing from the original text 
> helps identify which is the source to be 
> translated into further languages if the user 
> mail client allows.
>
>  This enables us to dispose of the 'original' 
> value which didn't lend itself well to being 
> graded on quality.
>
>  "Additionally, interactive implementations MAY 
> offer the user a choice from among the 
> available languages." so the qvalue may not 
> need to be bulletproof.
>
>  Comments?
>
>  Nik.
>
>  On 3 July 2015 at 09:46, Gunnar Hellström 
> <<mailto:[email-masked]>[email-masked]> 
> wrote:
>
>  The time is here when it can be possible in 
> some situations to select between using a 
> low-cost automatic speech-to-text generation 
> and a higher cost captioned telephony or 
> text-relay service (higher cost for someone, 
>  But I agree that it is very hard to set good 
> understandable values on a parameter expressing 
> the type or quality of this kind of service.
>
>  Gunnar
>
>
>
>    Nik Tomkinson 
> <<mailto:[email-masked]>[email-masked]> 
> wrote
>  <mailto:[email-masked]>[email-masked]
> 
> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>
>
>  <mailto:[email-masked]>[email-masked]
> 
> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>
>
>
>
>  --
>
> <http://datatracker.ietf.org/doc/draft-tomkinson-multilangcontent/>http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Experience should teach us to be most on our guard to protect liberty
when the government's purposes are beneficent.  Men born to freedom are
naturally alert to repel invasion of their liberty by evil-minded
rulers.  The greatest dangers to liberty lurk in insidious encroachment
by men of zeal, well-meaning but without understanding.
    --Louis D. Brandeis

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 05 Jul 2015 08:48:42 +0200

Another opportunity would be to convey a URI to the service provider who 
did (for mail) or can do(for real-time) the translation.
Then experience with different service provider's production could give 
some idea of the expected quality.
I can see great value in that for the real-time case, when the calling 
user has a favourite translator (e.g. relay service), and provides that 
as a hint if languages or modalities in the call does not match. Then 
the callee do not need to just take a service provider by chance that 
seem to match the language/modality profile but can take the one 
proposed by the caller.

After working with the needs for emergency services to work across 
Europe for some time now, I think this is one of the few workable 
solutions. The user expresses both the language/modality needs and 
provides a URI to a favourite translation service provider, and the 
callee tries to fulfill the language/modality needs either by a matching 
original call taker or by invoking the proposed translation provider.

/Gunnar

Randall Gellens skrev den 2015-07-05 03:49:
> My recollection is that this was discussed in email prior to Dallas, 
> but that's not important.
>
> I am a strong proponent of keeping things as simple as possible, 
> provided there is a way to extend them if experience shows that it is 
> needed.  So, I think we should stick with the original suggestion of 
> three values ("original", "human", "automated"). This is simple enough 
> to be implementable and functional enough to be useful in providing a 
> hint that may help the client choose the best version for the user.  
> If we try and capture the various nuances of quality we will end up 
> with a very complex mechanism that is unlikely to be any more useful 
> in real life. Let's go with the simple approach now.  If, after some 
> deployment experience we realize that we really do need extra 
> complexity, we can extend the mechanism then.
>
>>  To deal with the issue with having only original/human/automated, 
>> what about the following?:
>>
>>
>>  The Translation-Type SHOULD NOT appear in the original 
>> (untranslated) part but it SHOULD appear in translated content.
>>
>>  Having this missing from the original text helps identify which is 
>> the source to be translated into further languages if the user mail 
>> client allows.
>>
>>  This enables us to dispose of the 'original' value which didn't lend 
>> itself well to being graded on quality.
>>
>>  "Additionally, interactive implementations MAY offer the user a 
>> choice from among the available languages." so the qvalue may not 
>> need to be bulletproof.
>>
>>  Comments?
>>
>>  Nik.
>>
>> <<mailto:[email-masked]>[email-masked]> wrote:
>>
>>  The time is here when it can be possible in some situations to 
>> select between using a low-cost automatic speech-to-text generation 
>> and a higher cost captioned telephony or text-relay service (higher 
>> cost for someone, not always the end-user).
>>
>>  But I agree that it is very hard to set good understandable values 
>> on a parameter expressing the type or quality of this kind of service.
>>
>>  Gunnar
>>
>>
>>
>> <<mailto:[email-masked]>[email-masked]> wrote

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Eric Burger <[email-masked]>
Date: Sun, 5 Jul 2015 03:17:23 -0400

I’m agreeing here with Paul. /Maybe/ we could annotate something that was machine translated. However, My justification is not to say how good the translation is, but to let the user know they are NOT seeing the original content.
 
> On Jul 3, 2015, at 12:00 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Yes. It is my understanding (2nd hand) there there are subjective decisions (preferences) when choosing a translation service.
> 
> While I can see how having a rating attached might be conceptually appealing, it is hard to imagine how it would be deployed in a way that is useful. And it seems likely to be subject to endless haggling.
> 
> Seems like a rat hole.
> 
> 	Thanks,
> 	Paul
> 
>> Gunnar
>> 
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 05 Jul 2015 12:20:40 -0400

Gunnar,

I understand what you are suggesting, but I don't believe it is 
workable. This seems to mean that the caller would select the service 
while the callee would engage the service in the call if needed. Yet it 
is likely to be the caller who has a business relationship with the 
service, while the callee does not. Gets complicated quickly.

ISTM it makes more sense to first figure out what is/isn't possible 
without translation, and then for a party that finds a translation 
service beneficial to engage one. Then the only concern is that both 
parties don't independently try to introduce equivalent translation 
services.

For instance, a deaf caller might offer video media marked for sign 
language, and audio media on hold. If the answer doesn't accept the 
video, or doesn't indicate support for sign language, the caller could 
then conference in translation service, using the 3pcc transcoding model 
specified in rfc5369. (If that will take time, the deaf caller's UA 
could stream recorded media over the audio channel in the meantime.)

Or, to get fancier, it would be possible to use preconditions to defer 
alerting the callee until this is all sorted out.

My point is to let the participant who wants translation handle to setup 
of translation rather than depending on the other party to do something.

	Thanks,
	Paul

On 7/5/15 2:48 AM, Gunnar Hellström wrote:
>> hint that may help the client choose the best version for the user. If
>> we try and capture the various nuances of quality we will end up with
>> a very complex mechanism that is unlikely to be any more useful in
>> real life. Let's go with the simple approach now.  If, after some

---

From: Randall Gellens <[email-masked]>
Date: Sun, 5 Jul 2015 12:43:25 -0700

Having the caller provide a URI to the caller's 
preferred service might possibly work for 
person-to-person calling, but seems completely 
unworkable for the call center and emergency 
services cases.

At 8:48 AM +0200 7/5/15, Gunnar Hellström wrote:

>  Another opportunity would be to convey a URI to 
> the service provider who did (for mail) or can 
> do(for real-time) the translation.
>  Then experience with different service 
> provider's production could give some idea of 
> the expected quality.
>  I can see great value in that for the real-time 
> case, when the calling user has a favourite 
> translator (e.g. relay service), and provides 
> that as a hint if languages or modalities in 
> the call does not match. Then the callee do not 
> need to just take a service provider by chance 
> that seem to match the language/modality 
> profile but can take the one proposed by the 
> caller.
>
>  After working with the needs for emergency 
> services to work across Europe for some time 
> now, I think this is one of the few workable 
> solutions. The user expresses both the 
> language/modality needs and provides a URI to a 
> favourite translation service provider, and the 
> callee tries to fulfill the language/modality 
> needs either by a matching original call taker 
> or by invoking the proposed translation 
> provider.
>
>  /Gunnar
>
>
>> original suggestion of three values 
>> ("original", "human", "automated"). This is 
>> simple enough to be implementable and 
>> functional enough to be useful in providing a 
>> hint that may help the client choose the best 
>> version for the user.  If we try and capture 
>> the various nuances of quality we will end up 
>> with a very complex mechanism that is unlikely 
>> to be any more useful in real life. Let's go 
>> with the simple approach now.  If, after some 
>> deployment experience we realize that we 
>>>   The Translation-Type SHOULD NOT appear in 
>>> the original (untranslated) part but it 
>>> SHOULD appear in translated content.
>>>
>>>   "Additionally, interactive implementations 
>>> MAY offer the user a choice from among the 
>>> understandable values on a parameter 
>>> expressing the type or quality of this kind 
>>> of service.
>>>
>>>   Gunnar
>>>
>>>
>>>

-------------- Randomly selected tag: ---------------
Surstrommingspremier (SEUR-stomins-prem-ya; Swedish; noun): The
first day of the year when it is acceptable eat Surstromming,
extremely foul-smelling fermented herring (banned in some apartment
complexes, airplanes, etc.) -- literally, "sour fish premier."

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 05 Jul 2015 22:35:50 +0200

Paul,
Yes, I agree that for most cases it is best that the party, who knows a 
service that will do the translation, does the invocation.

And, yes ,in that scenario the 3PCC method seems suitable.

My proposal to send the service provider URI together with the modality 
indications was for the case when there are strong policy reasons why 
one party would do the invocation, but little chance that that party 
would have access to an up-to-date information on available translation 
providers.
That could be the case for the emergency service calling in a 
multi-language environment, also including support for sign language users.

Since both you and Randall think it is not doable, we can try to use the 
principle that the party, who knows a service that will do the 
translation, does the invocation.

That brings us back to a need for more stringent language/modality 
negotiation in order to avoid both double invocation of services when 
one or none is required, and also avoid no invocation when one is needed.

Paul Kyzivat skrev den 2015-07-05 18:20:
> while the callee would engage the service in the call if needed. Yet 
> it is likely to be the caller who has a business relationship with the 
> then conference in translation service, using the 3pcc transcoding 
> model specified in rfc5369. (If that will take time, the deaf caller's 
> UA could stream recorded media over the audio channel in the meantime.)
>
> My point is to let the participant who wants translation handle to 
> setup of translation rather than depending on the other party to do 
> something.
OK, it might be likely that both parties "want" translation, but one has 
better knowledge about how to get the required service and has business 
relations with the service. So then it is preferred that that party invokes.

Good
/Gunnar

---

From: Nik Tomkinson <[email-masked]>
Date: Sun, 5 Jul 2015 22:10:42 +0100

Thanks again for the responses.

I think that I will add the original suggestion of:

into the next version of the non-real-time I-D and (as Randall suggests) if
during some deployment trials we find that making the distinction between
'automated' and 'human' is not granular enough (or there are other changes
required) we can update it further.

I will start on this update now and have it ready to submit before the
cut-off deadline tomorrow night (23:59 UTC Monday).

Nik.

On 5 July 2015 at 08:17, Eric Burger <[email-masked]> wrote:

> I’m agreeing here with Paul. /Maybe/ we could annotate something that was
> machine translated. However, My justification is not to say how good the
> translation is, but to let the user know they are NOT seeing the original
> content.
>
>
> appealing, it is hard to imagine how it would be deployed in a way that is
> useful. And it seems likely to be subject to endless haggling.
>
> Seems like a rat hole.
>
> Thanks,
> Paul
>
> Gunnar
>
>

--

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 05 Jul 2015 18:04:46 -0400

> type-token := "original" / "human" / "automated"

This seems "ok" - more or less harmless and possibly helpful in some cases.

But I'm concerned that it will lead to an assumption that "human" is 
*better* than "automated". That is probably true in most practical cases 
today. But surely there are *some* automated translations that are 
better than *some* human translations. And that will become the case 
more often in the future.

	Thanks,
	Paul

> into the next version of the non-real-time I-D and (as Randall suggests)
> if during some deployment trials we find that making the distinction
> between 'automated' and 'human' is not granular enough (or there are
> other changes required) we can update it further.
>
> On 5 July 2015 at 08:17, Eric Burger <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I’m agreeing here with Paul. /Maybe/ we could annotate something
>     that was machine translated. However, My justification is not to say
>     how good the translation is, but to let the user know they are NOT
>     seeing the original content.
>
>>     On Jul 3, 2015, at 12:00 PM, Paul Kyzivat <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     appealing, it is hard to imagine how it would be deployed in a way
>>     that is useful. And it seems likely to be subject to endless haggling.
>>
>>     Seems like a rat hole.
>>
>>     Thanks,
>>     Paul
>>
>>>     Gunnar
>>>
>>>
>>>>      Nik Tomkinson <[email-masked]
>>>>     <mailto:[email-masked]>> wrote
>>>>     [email-masked] <mailto:[email-masked]>
>>>     [email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Nik Tomkinson <[email-masked]>
Date: Sun, 5 Jul 2015 23:18:45 +0100

Hi Paul,

yes, they were my thoughts behind suggesting the qvalue to identify the
quality of the translation and to avoid the implication that a machine
translation is always worse than a human one. But I think I would prefer to
start off simply and add complexity if it is required in a later version of
the draft. The qvalue parameter could be added retrospectively to the
Translation-Type field.

I think this will be an area to discuss in Prague and also explore/test
when doing some trial implementations.

Thanks,

Nik.

On 5 July 2015 at 23:04, Paul Kyzivat <[email-masked]> wrote:

> today. But surely there are *some* automated translations that are better
> than *some* human translations. And that will become the case more often in
> the future.
>
>         Thanks,
>         Paul
>
>>>> select

--

---

From: Randall Gellens <[email-masked]>
Date: Sun, 5 Jul 2015 18:05:00 -0700

At 6:04 PM -0400 7/5/15, Paul Kyzivat wrote:

>  But I'm concerned that it will lead to an assumption that "human" 
> is *better* than "automated". That is probably true in most 
> practical cases today. But surely there are *some* automated 
> translations that are better than *some* human translations. And 
> that will become the case more often in the future.

Keep in mind that the only use for the attribute will be at the 
receiving client.  If, over time and on average, automated 
translations become on par or better than human translations, the end 
user and/or client can stop preferring human and go with the more 
preferred language rather than the more preferred translation method. 
In the meantime, it might be useful.

-------------- Randomly selected tag: ---------------
In the United States the majority undertakes to supply a multitude of
ready-made opinions for the use of individuals, who are thus relieved
from the necessity of forming opinions of their own
      --Alexis de Tocqueville

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 06 Jul 2015 09:01:30 +0200

Follow-up questions:
1. What will be the default? Just unspecified I assume.

2. Would there be a need for a value representing all translation types 
except original?  (=translated but unknown how) I can imagine some use 
of that, but I think it is acceptable to ignore that need. The user with 
that need would need to just take one of the other values.

3. Is there a need to describe how the coding can be extended?

4. Will this be a media level parameter or a session level parameter or 
both? I assume it makes most sense on the media level, so that it can be 
described e.g. that the audio carries original speech, while the text 
carries automated captions.

/Gunnar

Paul Kyzivat skrev den 2015-07-06 00:04:
> *better* than "automated". That is probably true in most practical 
> cases today. But surely there are *some* automated translations that 
> are better than *some* human translations. And that will become the 
> case more often in the future.
>
>     Thanks,
>     Paul
>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 06 Jul 2015 09:24:52 +0200

One reason for the need to convey a translation service provider URI is 
that the emergency service RFCs 6443 and 6881 forbids the calling user 
to invoke three-party calling.

For example RFC 6443, chapter 13 says "Services such as call waiting, 
call transfer, three-way calling, and hold should be disabled."

If then the user is in a foreign language environment where the PSAP 
barely can have a clue on how to find the right relay service, and the 
user has a good relay service URI configured, well capable of handling 
the user's language and modality, what is then best?

1) Break against RFC 6881 and 6443 and have the user terminal invoke the 
three-party call? The wording in these RFCs may be interpreted to have 
some room for such deviations.
2) Or convey the relay service URI to the PSAP for invocation.

The discussion so far leads towards conclusion 1. It is ok for me, I 
just wanted it confirmed by showing the whole situation.

(there will always be complementing slow manual procedures, when the 
PSAP needs to figure out a reasonable way to handle the call, but this 
discussion is for the rapid automated way that should handle most cases.)

/Gunnar

Gunnar Hellström skrev den 2015-07-05 22:35:
> Paul,
> Yes, I agree that for most cases it is best that the party, who knows 
> a service that will do the translation, does the invocation.
>
> My proposal to send the service provider URI together with the 
> modality indications was for the case when there are strong policy 
> reasons why one party would do the invocation, but little chance that 
> that party would have access to an up-to-date information on available 
> translation providers.
> Since both you and Randall think it is not doable, we can try to use 
> the principle that the party, who knows a service that will do the 
>> it is likely to be the caller who has a business relationship with 
>> the service, while the callee does not. Gets complicated quickly.
>>
>> video, or doesn't indicate support for sign language, the caller 
>> could then conference in translation service, using the 3pcc 
>> transcoding model specified in rfc5369. (If that will take time, the 
>> deaf caller's UA could stream recorded media over the audio channel 
>> in the meantime.)
>>
>> Or, to get fancier, it would be possible to use preconditions to 
>> defer alerting the callee until this is all sorted out.
>>
> OK, it might be likely that both parties "want" translation, but one 
> has better knowledge about how to get the required service and has 
> business relations with the service. So then it is preferred that that 
> party invokes.
>
> Good
> /Gunnar
>>
>>     Thanks,
>>     Paul
>>

---

From: Eric Burger <[email-masked]>
Date: Mon, 6 Jul 2015 04:43:43 -0400

> On Jul 6, 2015, at 3:24 AM, Gunnar Hellström <[email-masked]> wrote:
> 
> One reason for the need to convey a translation service provider URI is that the emergency service RFCs 6443 and 6881 forbids the calling user to invoke three-party calling.

6443 is informational and 6881 is a BCP. No problem to do something that works that is ‘forbidden.’

> For example RFC 6443, chapter 13 says "Services such as call waiting, call transfer, three-way calling, and hold should be disabled.”

Note the use of ‘should.’  I do not think anyone will complain if one interprets this as, “Should be disabled, unless the user will die if she does not setup a three-way call with her translation service.”

> If then the user is in a foreign language environment where the PSAP barely can have a clue on how to find the right relay service, and the user has a good relay service URI configured, well capable of handling the user's language and modality, what is then best?
> 
> 1) Break against RFC 6881 and 6443 and have the user terminal invoke the three-party call? The wording in these RFCs may be interpreted to have some room for such deviations.

Beyond the wording in the RFCs, there is a reason the IETF is not the protocol police. In retrospect, it may be safe to say the RFCs’ suggestions are wrong.

> 2) Or convey the relay service URI to the PSAP for invocation.

Why not?

> 
> The discussion so far leads towards conclusion 1. It is ok for me, I just wanted it confirmed by showing the whole situation.
> 
> (there will always be complementing slow manual procedures, when the PSAP needs to figure out a reasonable way to handle the call, but this discussion is for the rapid automated way that should handle most cases.)
> 
> /Gunnar
> 
>> Yes, I agree that for most cases it is best that the party, who knows a service that will do the translation, does the invocation.
>> 
>> My proposal to send the service provider URI together with the modality indications was for the case when there are strong policy reasons why one party would do the invocation, but little chance that that party would have access to an up-to-date information on available translation providers.
>> That could be the case for the emergency service calling in a multi-language environment, also including support for sign language users.
>> 
>> Since both you and Randall think it is not doable, we can try to use the principle that the party, who knows a service that will do the translation, does the invocation.
>> 
>> That brings us back to a need for more stringent language/modality negotiation in order to avoid both double invocation of services when one or none is required, and also avoid no invocation when one is needed.
>> 
>>> I understand what you are suggesting, but I don't believe it is workable. This seems to mean that the caller would select the service while the callee would engage the service in the call if needed. Yet it is likely to be the caller who has a business relationship with the service, while the callee does not. Gets complicated quickly.
>>> 
>>> ISTM it makes more sense to first figure out what is/isn't possible without translation, and then for a party that finds a translation service beneficial to engage one. Then the only concern is that both parties don't independently try to introduce equivalent translation services.
>>> 
>>> For instance, a deaf caller might offer video media marked for sign language, and audio media on hold. If the answer doesn't accept the video, or doesn't indicate support for sign language, the caller could then conference in translation service, using the 3pcc transcoding model specified in rfc5369. (If that will take time, the deaf caller's UA could stream recorded media over the audio channel in the meantime.)
>>> 
>>> Or, to get fancier, it would be possible to use preconditions to defer alerting the callee until this is all sorted out.
>>> 
>>> My point is to let the participant who wants translation handle to setup of translation rather than depending on the other party to do something.
>> OK, it might be likely that both parties "want" translation, but one has better knowledge about how to get the required service and has business relations with the service. So then it is preferred that that party invokes.
>> 
>> Good
>> /Gunnar
>>> 
>>>    Thanks,
>>>    Paul
>>>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 06 Jul 2015 11:22:23 +0200

Thanks Eric for sensible answers.

>> 2) Or convey the relay service URI to the PSAP for invocation.
One example of a procedure for such invocation is in EENA NG112 LTD and 
NENA NG9-1-1 i3 08-003 procedure for third party invocation, (chapter 9) 
where the third party service, who happens to get the emergency call 
first, refers back to the emergency caller to make the call to 
urn:service:sos with the third party URI in the Referred-by  field. The 
PSAP is then supposed to conference-in the third party. ( I have not 
seen how they deduce that the third party shall be conferenced-in, but 
their address is anyway conveyed to the PSAP. )

---

From: Eric Burger <[email-masked]>
Date: Mon, 6 Jul 2015 05:53:40 -0400

> On Jul 6, 2015, at 5:22 AM, Gunnar Hellström <[email-masked]> wrote:
> 
> One example of a procedure for such invocation is in EENA NG112 LTD and NENA NG9-1-1 i3 08-003 procedure for third party invocation, (chapter 9) where the third party service, who happens to get the emergency call first, refers back to the emergency caller to make the call to urn:service:sos with the third party URI in the Referred-by  field. The PSAP is then supposed to conference-in the third party. ( I have not seen how they deduce that the third party shall be conferenced-in, but their address is anyway conveyed to the PSAP. )

I was thinking of one of Paul’s comments. I suppose the problem can be that an attacker can put ‘interesting’ URI’s in for “conference services” that actually are DDoS attack victims. We could make it impossible for a caller to put in their preferred translation service or we can point out the vulnerability and say the PSAP needs to have policies in place such that it is clear the translation service URI is a suggestion, not a request.

We have a similar (but not quite the same) problem with today’s VRS in the U.S. with respect to fraud. One could imagine a PSAP has contracted with economical, experienced, and very good translation services. An indigent individual may have been coerced to sign up with a very expensive, poor quality sham of a translation service. We need to make clear in the “how to use SLIM” section of the document that it is up to the PSAP (? my guess here) to decide whether or not to take the caller’s suggestion (note I am not calling it a request) for a particular translation service provider.

---

From: Nik Tomkinson <[email-masked]>
Date: Mon, 6 Jul 2015 12:18:49 +0100

1 - Yes, and if the Translation-Type value is missing then the recipient's
email client will have to select the translation based just on the
preferred language only and ignore any user type preference.
2 - I think for now the simplicity outweighs any use case for that. At the
moment, I can't think of any case where the recipient would make use of a
translated-method-unknown value
3 - Not at this early stage but maybe in the next version of the draft
4 - I think this question is for the real-time implementation (if I
understand it correctly)

Thanks,

Nik.

On 6 July 2015 at 08:01, Gunnar Hellström <[email-masked]>
wrote:

> except original?  (=translated but unknown how) I can imagine some use of
> that, but I think it is acceptable to ignore that need. The user with that
> need would need to just take one of the other values.
>

--

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 06 Jul 2015 14:40:20 +0200

Nik Tomkinson skrev den 2015-07-06 13:18:
> 1 - Yes, and if the Translation-Type value is missing then the 
> recipient's email client will have to select the translation based 
> just on the preferred language only and ignore any user type preference.
Good.
> 2 - I think for now the simplicity outweighs any use case for that. At 
> the moment, I can't think of any case where the recipient would make 
> use of a translated-method-unknown value
Good
> 3 - Not at this early stage but maybe in the next version of the draft
A thought on extension possibilities is always good to have initially. 
If not briefly thought of initially, extensions are commonly causing 
interop problems when introduced later.
But here it might be a simple statement: "other values may be added in 
the future."  The usual rule that implementations finding another value 
should ignore it.

By the way, how about multiple values? A video containing both the 
original sign language user and interpreter translating to speech 
visible in the same video would need both specified.
> 4 - I think this question is for the real-time implementation (if I 
The video example above with both signed original and spoken translation 
in the video medium would be valid for the stored case as well, carrying 
original and translated in the same medium. Will you have separate 
specifications per medium in the stored case, or one single session 
declaration? If just session declaration, there will be a need for 
multiple specifications of translation, with at least one per medium.

/Gunnar
>
> Thanks,
>
> Nik.
>
> On 6 July 2015 at 08:01, Gunnar Hellström <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Follow-up questions:
>     2. Would there be a need for a value representing all translation
>     types except original?  (=translated but unknown how) I can
>     imagine some use of that, but I think it is acceptable to ignore
>     that need. The user with that need would need to just take one of
>     the other values.
>
>     4. Will this be a media level parameter or a session level
>     parameter or both? I assume it makes most sense on the media
>     level, so that it can be described e.g. that the audio carries
>     original speech, while the text carries automated captions.
>
>     /Gunnar
>
>
>         But I'm concerned that it will lead to an assumption that
>         "human" is *better* than "automated". That is probably true in
>         most practical cases today. But surely there are *some*
>         automated translations that are better than *some* human
>         translations. And that will become the case more often in the
>         future.
>
>             Thanks,
>             Paul
>
>             <mailto:[email-masked]>
>             <mailto:[email-masked]
>             <mailto:[email-masked]>>> wrote:
>
>                     On Jul 3, 2015, at 12:00 PM, Paul Kyzivat
>                 <[email-masked] <mailto:[email-masked]>
>                     <mailto:[email-masked]
>                 <mailto:[email-masked]>>> wrote:
>
>                         I see some value of this kind of parameter
>                     also for the real-time
>                         case.
>                     some situations to select
>                         higher cost captioned telephony or text-relay
>                     service (higher
>                         cost for
>                     understandable
>                         values on a
>                         <[email-masked]
>                         <mailto:[email-masked]>
>                             <mailto:[email-masked]
>                         <mailto:[email-masked]>>> wrote
>                             In many IETF working groups, when there is
>                         such a proposal,
>                             there is a
>                             second ones say we can never capture all
>                         the nuances and
>                             subtleties of
>                         <mailto:[email-masked] <mailto:[email-masked]>>
>                     <mailto:[email-masked] <mailto:[email-masked]>>
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>             [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>
>     [email-masked] <mailto:[email-masked]>
>     +46 708 204 288 <tel:%2B46%20708%20204%20288>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Jul 2015 10:02:04 -0400

> discussion is for the rapid automated way that should handle most cases.)

(1) makes more sense to me than the alternatives.

OTOH, I can see the rationale for not *waiting* for the relay setup 
before putting the call through to the PSAP. So some signaling that 
indicates early that relay service is "on the way" might be helpful to 
allow the PSAP to make good decisions about whether to seek translation 
services on its own.

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 06 Jul 2015 16:21:40 +0200

Paul Kyzivat skrev den 2015-07-06 16:02:
> allow the PSAP to make good decisions about whether to seek 
> translation services on its own.
Yes, that is what we have said in ETSI TS 101 470:
" The call establishment procedure shall enable call setup requests to 
go to both the emergency service and the relay service in parallel."

That can lead to some frustration if the emergency service answers 
first, but that frustration can be reduced by using real-time text 
between the PSAP and the user until full modality support is available 
by the relay.

But it will likely provide a better total result than connecting the 
services in series with relay first.

Thanks,
Gunnar

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 6 Jul 2015 10:25:55 -0400

Plus, increasingly, there are hybrids (automated followed by human editing
and maybe vice versa, such as a grammar checker), which are apparently
quite common for routine (business and technical, rather than literature)
translations.

---

From: Nik Tomkinson <[email-masked]>
Date: Mon, 6 Jul 2015 15:53:59 +0100

In the latest I-D I use the statement:

"A value of 'automated' is used when a language message part has been
translated by an electronic agent without proofreading or subsequent
correction."

I should have clarified this earlier. I have considered that any
translation/interpretation step where a human has taken a role is
considered 'human'.

Nik.

--

---

From: Nik Tomkinson <[email-masked]>
Date: Mon, 6 Jul 2015 16:30:23 +0100

Thanks for the comments:
3 - I will add 'other values may be added in the future' in today's draft
version - thanks.

I see, for the video example it would be human x 2 (original human signing
and human interpreting) but I can see there may be the case of some media
that has an automated translated/interpreted content alongside human text,
speech or signing. This is something that I will put on my list for further
thought and discussion for the next version of the draft but in order to
get a new version submitted before the cut-off time this evening, I will
stick to just one value.

Can you expand on your last question? I'm not sure what you mean by
'session' in a non-real-time single email scenario. The intention is to
have the Translation-Type specified once per 'language message part' (eg.
original, text translation or media translation).

Nik.

On 6 July 2015 at 13:40, Gunnar Hellström <[email-masked]>
wrote:

> the moment, I can't think of any case where the recipient would make use of
> a translated-method-unknown value
>
> Good
>
> A thought on extension possibilities is always good to have initially. If
> not briefly thought of initially, extensions are commonly causing interop
> problems when introduced later.
> But here it might be a simple statement: "other values may be added in the
> future."  The usual rule that implementations finding another value should
> ignore it.
>
> original sign language user and interpreter translating to speech visible
> in the same video would need both specified.
>
> declaration? If just session declaration, there will be a need for multiple
> specifications of translation, with at least one per medium.
>
> /Gunnar
>
>
>  Thanks,
>
>  Nik.
>
> SLIM mailing [email-masked]://www.ietf.org/mailman/listinfo/slim
>
>
> --
> [email-masked]
> +46 708 204 288
>
>

--

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 06 Jul 2015 17:41:55 +0200

Nik Tomkinson skrev den 2015-07-06 17:30:
> 'session' in a non-real-time single email scenario. The intention is 
> to have the Translation-Type specified once per 'language message 
> part' (eg. original, text translation or media translation).
Well, say media description or what term you use for the declaration.

A simple example would be a video file with audio track and timed text, 
with the video containing an original sign language presentation, 
interpreted to speech by a human interpreter in the audio track, and the 
interpreter talking into a speech-to-text generator, creating the 
automated timed-text track.

What would the translation declaration(s) look like for this creation so 
that all interested parties can judge if they get what they want?

Thanks

Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Tue, 7 Jul 2015 10:56:35 -0700

At 4:43 AM -0400 7/6/15, Eric Burger wrote:

>>  One reason for the need to convey a 
>> translation service provider URI is that the 
>> emergency service RFCs 6443 and 6881 forbids 
>> the calling user to invoke three-party calling.

The text there is saying that the best practice 
for a device initiating an emergency call is to 
disable services that could interrupt the call, 
such as call waiting and third-party calling.  If 
the third-party call is initiated before or in 
parallel with the emergency call, the text 
wouldn't apply anyway, and if the third-party 
call is initiated during the emergency call in 
order to better serve the user's needs, then this 
is exactly why the text uses "SHOULD" instead of 
"MUST."  The word "SHOULD" means that a client is 
supposed to follow the direction unless there is 
an overriding reason not to, and the consequences 
of doing so are understood.  Both of those apply 
in the case under discussion.

>
>  6443 is informational and 6881 is a BCP. No 
> problem to do something that works that is 
> 'forbidden.'
>
>>  For example RFC 6443, chapter 13 says 
>> "Services such as call waiting, call transfer, 
>> three-way calling, and hold should be 
>> disabled."
>
>  Note the use of 'should.'  I do not think 
> anyone will complain if one interprets this as, 
> "Should be disabled, unless the user will die 
> if she does not setup a three-way call with her 
> translation service."
>
>>  If then the user is in a foreign language 
>> environment where the PSAP barely can have a 
>> clue on how to find the right relay service, 
>> and the user has a good relay service URI 
>> configured, well capable of handling the 
>> user's language and modality, what is then 
>> best?
>>
>>  1) Break against RFC 6881 and 6443 and have 
>> the user terminal invoke the three-party call? 
>> The wording in these RFCs may be interpreted 
>> to have some room for such deviations.
>
>  Beyond the wording in the RFCs, there is a 
> reason the IETF is not the protocol police. In 
> retrospect, it may be safe to say the RFCs' 
> suggestions are wrong.
>
>>  The discussion so far leads towards conclusion 
>> 1. It is ok for me, I just wanted it confirmed 
>> by showing the whole situation.
>>
>>  (there will always be complementing slow 
>> manual procedures, when the PSAP needs to 
>> figure out a reasonable way to handle the 
>> call, but this discussion is for the rapid 
>> automated way that should handle most cases.)
>>
>>  /Gunnar
>>
>>>  Yes, I agree that for most cases it is best 
>>> that the party, who knows a service that will 
>>> do the translation, does the invocation.
>>>
>>>  My proposal to send the service provider URI 
>>> together with the modality indications was 
>>> for the case when there are strong policy 
>>> reasons why one party would do the 
>>> invocation, but little chance that that party 
>>>  That could be the case for the emergency 
>>> service calling in a multi-language 
>>> environment, also including support for sign 
>>> language users.
>>>
>>>  Since both you and Randall think it is not 
>>> doable, we can try to use the principle that 
>>> the party, who knows a service that will do 
>>> the translation, does the invocation.
>   >>
>>>  That brings us back to a need for more 
>>> stringent language/modality negotiation in 
>>> order to avoid both double invocation of 
>>> services when one or none is required, and 
>>> also avoid no invocation when one is needed.
>>>
>>>>  I understand what you are suggesting, but I 
>>>> don't believe it is workable. This seems to 
>>>> mean that the caller would select the 
>>>> service while the callee would engage the 
>>>> service in the call if needed. Yet it is 
>>>> likely to be the caller who has a business 
>>>> relationship with the service, while the 
>>>> callee does not. Gets complicated quickly.
>   >>>
>>>>  ISTM it makes more sense to first figure out 
>>>> what is/isn't possible without translation, 
>>>> and then for a party that finds a 
>>>> translation service beneficial to engage 
>>>> one. Then the only concern is that both 
>>>> parties don't independently try to introduce 
>>>> equivalent translation services.
>>>>
>>>>  For instance, a deaf caller might offer 
>>>> video media marked for sign language, and 
>>>> audio media on hold. If the answer doesn't 
>>>> accept the video, or doesn't indicate 
>>>> support for sign language, the caller could 
>>>> then conference in translation service, 
>>>> using the 3pcc transcoding model specified 
>>>> in rfc5369. (If that will take time, the 
>>>> deaf caller's UA could stream recorded media 
>>>> over the audio channel in the meantime.)
>>>>
>>>>  Or, to get fancier, it would be possible to 
>>>> use preconditions to defer alerting the 
>>>> callee until this is all sorted out.
>>>>
>>>>  My point is to let the participant who wants 
>>>> translation handle to setup of translation 
>>>> rather than depending on the other party to 
>>>> do something.
>>>  OK, it might be likely that both parties 
>>> "want" translation, but one has better 
>>> knowledge about how to get the required 
>>> service and has business relations with the 
>>> service. So then it is preferred that that 
>>> party invokes.
>>>
>>>  Good
>>>  /Gunnar
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>  Content-Transfer-Encoding: 7bit
>  Content-Disposition: attachment; filename="signature.asc"
>  Content-Type: application/pgp-signature;
>  	name=signature.asc
>  Content-Description: Message signed with OpenPGP using GPGMail
>
>  Attachment converted: TiLand:signature 415.asc (    /    ) (028C4061)

-------------- Randomly selected tag: ---------------
Progress is made on alternate Fridays.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 7 Jul 2015 10:58:10 -0700

At 10:25 AM -0400 7/6/15, Henning Schulzrinne wrote:

>  Plus, increasingly, there are hybrids (automated followed by human 
> editing and maybe vice versa, such as a grammar checker), which are 
> apparently quite common for routine (business and technical, rather 
> than literature) translations.

I think we should keep the mechanism simple, and say that any human 
involvement means the "human" tag should be used.

>
>  On Sun, Jul 5, 2015 at 6:04 PM, Paul Kyzivat 
> <<mailto:[email-masked]>[email-masked]> wrote:
>

-------------- Randomly selected tag: ---------------
It has always seemed to me that the most difficult part of building
a bridge would be the start.                      --Robert Benchley

---

From: Randall Gellens <[email-masked]>
Date: Tue, 7 Jul 2015 11:04:52 -0700

At 4:30 PM +0100 7/6/15, Nik Tomkinson wrote:

>  Thanks for the comments:
>  3 - I will add 'other values may be added in the future' in today's 
> draft version - thanks.

To clarify, I don't think we need an IANA registry for the values.  I 
think we will be fine saying that the only values are "original", 
"human", and "automated," and perhaps a parenthetical note that 
additional values could be defined in a future extension of the 
document.  It's probably more likely that any future extension would 
add modifiers rather than new values.

>
>  I see, for the video example it would be human x 2 (original human 
> signing and human interpreting) but I can see there may be the case 
> of some media that has an automated translated/interpreted content 
> alongside human text, speech or signing. This is something that I 
> will put on my list for further thought and discussion for the next 
> version of the draft but in order to get a new version submitted 
> before the cut-off time this evening, I will stick to just one 
> value.

We should keep things simple until we have deployment experience that 
shows we need something more complex.  If a video is sent as an email 
attachment, the most appropriate value can be used (e.g., "human" if 
there is some human involvement).

-------------- Randomly selected tag: ---------------
A state which owns but one language and one habit is feeble and fragile.
    --King Stephen, founder of the Hungarian state (and a saint).

---

From: Randall Gellens <[email-masked]>
Date: Tue, 7 Jul 2015 11:07:50 -0700

At 5:41 PM +0200 7/6/15, Gunnar Hellström wrote:

>>  Can you expand on your last question? I'm not 
>> sure what you mean by 'session' in a 
>> non-real-time single email scenario. The 
>> intention is to have the Translation-Type 
>> specified once per 'language message part' 
>> (eg. original, text translation or media 
>> translation).
>  A simple example would be a video file with 
> audio track and timed text, with the video 
> containing an original sign language 
> presentation, interpreted to speech by a human 
> interpreter in the audio track, and the 
> interpreter talking into a speech-to-text 
> generator, creating the automated timed-text 
> track.
>
>  What would the translation declaration(s) look 
> like for this creation so that all interested 
> parties can judge if they get what they want?

Unless you expect there to be several video files 
sent in the same email, some with timed text and 
some without, and some with an audio track and 
some without, and hence a need for the receiving 
client to choose one, I don't think we need to 
express the nuances of the video object.  If 
there is some original content, use "original", 
otherwise if there is some human involvement, use 
"human", otherwise use "automated".

-------------- Randomly selected tag: ---------------
It is the business of the future to be dangerous.

---

From: Brian Rosen <[email-masked]>
Date: Tue, 7 Jul 2015 14:20:49 -0400

In general, the PSAP wants to use it’s bridge, and NOT have the translation service use its bridge.  There are clearly circumstances where the PSAP bridge cannot be used and we need a way to make sure the translation service’s bridge can be used.

Brian

> On Jul 7, 2015, at 1:56 PM, Randall Gellens <[email-masked]> wrote:
> 
> The text there is saying that the best practice for a device initiating an emergency call is to disable services that could interrupt the call, such as call waiting and third-party calling.  If the third-party call is initiated before or in parallel with the emergency call, the text wouldn't apply anyway, and if the third-party call is initiated during the emergency call in order to better serve the user's needs, then this is exactly why the text uses "SHOULD" instead of "MUST."  The word "SHOULD" means that a client is supposed to follow the direction unless there is an overriding reason not to, and the consequences of doing so are understood.  Both of those apply in the case under discussion.
> 
> 
>> 
>> 6443 is informational and 6881 is a BCP. No problem to do something that works that is 'forbidden.'
>> 
>>> For example RFC 6443, chapter 13 says "Services such as call waiting, call transfer, three-way calling, and hold should be disabled."
>> 
>> Note the use of 'should.'  I do not think anyone will complain if one interprets this as, "Should be disabled, unless the user will die if she does not setup a three-way call with her translation service."
>> 
>> Beyond the wording in the RFCs, there is a reason the IETF is not the protocol police. In retrospect, it may be safe to say the RFCs' suggestions are wrong.
>>