Re: [Slim] Translation Quality or type

On 7/7/15 5:00 PM, Brian Rosen wrote:
> Of course it’s not enforceable, but since there are a finite number of VRS providers, the PSAP community can prevail upon them to do the right thing.  The worst case, where there are two bridges, is annoying but not fatal.
>
> What we need is clear labeling of what is requested, something we don’t have now, but slim will provide.
>
> The current NENA documents say that the outgoing proxy server adds a Referred-By header to the call.  The PSAP may use the URI of the Referred-by to bridge in the referring party, which is the CA at the outgoing proxy of the VRS provider.  This works exactly the way the current U.S. regulations say it should work, where first a two way is established between the CA and the caller and then the call is extended as a 9-1-1 call.  It wouldn’t work as well in Gunnar’s environment where the SIP service provider isn’t the relay provider, but something similar could work.
>
> For “direct routing”, where you don’t get the 2-way before a 3-way is established, the VRS provider (in the US) can still add the Referred-by, which would allow the PSAP to either use it, or it’s own choice of relay provider.  It’s a bit weird, in that there is no actual referral, it’s more of a “if you want me, here is how to get me”, but it would clearly work.

ISTM that a problem with the NG911 approach is that the mechanism for 
setting up the relay call is entirely different from the way it is done 
for other relay calls. So it becomes a path-less-used and hence less 
tested. It would be nice if the same technique was used for everyday 
calls and emergency calls, so that it was a well tested path.

> We might be better off with another mechanism that expressly states “A translation service is available at this URI”, which is the idea Gunnar has.  I think that is additive, not replacing the current proposed language tag mechanism.  You could imagine various forms of that which would include the source and destination language tags.  An out of country visitor might request translation to French, but if he is in Brazil, his preferred English to French service might not be helpful.

I can see how that might work if limited to US VRS service, especially 
if only for emergency calls. In that case a common law/contract can be 
in place to ensure that the translation service will accept the call.

In the more general case, possibly where clients of the service have to 
establish a business relationship with each provider, it won't work very 
well.

It is also necessary that the invocation of the translation service be 
standardized so the entity invoking it knows how to do so. We hopefully 
will soon have something for VRS service in the US, but it doesn't work 
this way. And it is a long way from there to having a standard for all 
the different sorts of translation (relay) service.

	Thanks,
	Paul

> Brian
>
>> On Jul 7, 2015, at 4:20 PM, Eric Burger <eburger@standardstrack.com> wrote:
>>
>> I don't see how either way is enforceable. If we say the PSAP has to take the caller's translation service, any sensible PSAP will feel free to ignore it, whether due to cost, liability, or protecting against the PSAP being the source of a DoS attack. Conversely, if a particular PSAP could use a hint for a translation service, it would be handy for the caller to provide one.
>>
>>
>>
>> Sent from my mobile device. Thanks be to LEMONADE: http://www.standardstrack.com/ietf/lemonade
>>
>>
>> -------- Original message --------
>> From: Brian Rosen <br@brianrosen.net>
>> Date: 07/07/2015 2:20 PM (GMT-05:00)
>> To: Randall Gellens <randy@qti.qualcomm.com>
>> Cc: Eric Burger <eburger@standardstrack.com>, slim@ietf.org
>> Subject: Re: [Slim] Translation Quality or type - or service provider
>>
>> 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 <randy@qti.qualcomm.com> wrote:
>>>
>>> At 4:43 AM -0400 7/6/15, Eric Burger wrote:
>>>
>>>>   > On Jul 6, 2015, at 3:24 AM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> 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.
>>>>
>>>>> 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
>>>>>
>>>>> 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.
>>>>>>
>>>>>> 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:
>>>>>>> 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.
>>>>>> 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
>>>>>>>
>>>>>>> On 7/5/15 2:48 AM, 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
>>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote:
>>>>   >>>>>
>>>>>>>>>> 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
>>>>>>>>>> <<mailto:gunnar.hellstrom@omnitor.se>gunnar.hellstrom@omnitor.se> wrote:
>>>>>>>>>>
>>>>>>>>>> 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:
>>>>>>>>>>
>>>>>>>>>> On Thu, Jul 02, 2015 at 11:09:30PM +0100,
>>>>>>>>>>    Nik Tomkinson
>>>>>>>>>> <<mailto:rfc.nik.tomkinson@gmail.com>rfc.nik.tomkinson@gmail.com> wrote
>>>>>>>>>>    a message of 109 lines which said:
>>>>>>>>>>
>>>>>>>>>> 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?
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SLIM mailing list
>>>>>>>>>> <mailto:SLIM@ietf.org>SLIM@ietf.org
>>>>>>>>>>
>>>>>>>>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SLIM mailing list
>>>>>>>>>> <mailto:SLIM@ietf.org>SLIM@ietf.org
>>>>>>>>>>
>>>>>>>>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>> Multiple Language Content Type Internet Draft:
>>>>>>>>>>
>>>>>>>>>> <http://datatracker.ietf.org/doc/draft-tomkinson-multilangcontent/>http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/
>>>>   >>>>>>
>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SLIM mailing list
>>>>>>>>>> SLIM@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SLIM mailing list
>>>>>>> SLIM@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>>
>>>>>
>>>>> --
>>>>> -----------------------------------------
>>>>> Gunnar Hellström
>>>>> Omnitor
>>>>> gunnar.hellstrom@omnitor.se
>>>>> +46 708 204 288
>>>>>
>>>>> _______________________________________________
>>>>   > SLIM mailing list
>>>>> SLIM@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>
>>>>
>>>> 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)
>>>> _______________________________________________
>>>> SLIM mailing list
>>>> SLIM@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/slim
>>>
>>>
>>>
>>> --
>>> Randall Gellens
>>> Opinions are personal;    facts are suspect;    I speak for myself only
>>> -------------- Randomly selected tag: ---------------
>>> Progress is made on alternate Fridays.
>>>
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>>
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>