Subject: [Slim] I-D Action: draft-ietf-slim-use-cases-01.txt

From: [email-masked]
Date: Thu, 07 Apr 2016 05:13:00 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Selection of Language for Internet Media of the IETF.

        Title           : SLIM Use Cases
        Author          : Natasha Rooney
	Filename        : draft-ietf-slim-use-cases-01.txt
	Pages           : 7
	Date            : 2016-04-07

Abstract:
   Use cases for selection of language for internet media.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-slim-use-cases/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-slim-use-cases-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-use-cases-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Natasha Rooney <[email-masked]>
Date: Thu, 7 Apr 2016 12:21:45 +0000

Ahead of our meeting today I published a mildly updated and cleaner version of the use cases document.

Speak to you all later!

Natasha

Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>

On Apr 7, 2016, at 9:13 AM, [email-masked]<mailto:[email-masked]> wrote:

       Title           : SLIM Use Cases
       Author          : Natasha Rooney

Abstract:

_______________________________________________
SLIM mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/slim

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 7 Apr 2016 11:29:20 -0700

----------
Use case 2.4, change the text:

Old:
       An answering service will have no guidance to which is
       the preferred modality and may select to use the modality that is
       the callers last resort even if the preferred alternative is
       available.

To:
       An answering service will have no guidance to which is
       the preferred modality and thus all supported modalities
       might be set up.  The caller and answerer then use the
       preferred modalities and ignore the non-preferred ones.

The text:

Old:
    In order to not miss any
    calls, the indication of text as last resort would be desirable.

    o  Solution: need coding of an absolute preference: hi, med, lo
       together with the tag.

Should be deleted.  An absolute preference is not needed.  The worst 
case outcome is that unused media streams are established.

----------
In use case 2.5, replace the text:

Old:
    (There is no current solution that says that the
    text path is important.  The answering part may see it as an
    alternative.)

    o  Solution: Need for preference indication per modality

New:
    Both modalities are established, and used as preferred by the humans.

    o  Solution: Possible

----------
Use case 2.5.1, replace the text:

Old:
    There currently are methods to indicate that the call shall fail if a
    language is not met, but that may be too drastic for some users
    including the one in the above scenario (Section 2.5).  It may be
    important to be able to connect and just say something, or use
    residual hearing to get something back when the voice is familiar.
    o  Possible solution: coding of an absolute preference together with
       the tag could solve this case if used together with the
       directional indications.  For example:

    "preference: hi, med, lo"

    Another solution would be to indicate required grouping of media,
    however this raises the complexity level.

New:
    There currently are methods to indicate if the call should fail
    or proceed when no languages are in common.  In situations such
    as the above scenario (Section 2.5), it may be important to be
    able to connect and just say something, or use residual hearing
    to get something back when the voice is familiar.  With emergency
    calls, it is useful for the PSAP call taker to be able to hear
    background and anciliary sounds even if unable to speak to the
    caller.

    o  Solution: Possible

----------
In use case 2.6, change:

OLD:
    direction and find the only possible combination.

    o  Solution: Need for preference indication per modality

New:
    direction and find possible combinations.

    o  Solution: Possible

----------
Use cases 2.7, 2.8:

Delete "and absolute level of preference indication" from Solution.

----------
Section 3:

Typo in line #2: "language of" should be "language or"
Typo in line #5: "allow give" should choose one.

Delete "as well as an indication of absolute preference" from second paragraph.

Delete "seem to be needed" from end of last sentence of second paragraph.

----------
Section 4: I think this is more properly a privacy consideration, so 
consider adding a privacy considerations section with this text, and 
changing the security considerations to say something such as "no 
additional security risks have been identified by the ability to 
indicate language."

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Your analyst has you mixed up with another patient.  Don't believe a
thing he tells you.

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 8 Apr 2016 00:26:31 +0200

Randall,
Sadly very few of your change proposals for the use case document 
matches my view of the needs we have and the requirements they raise.

See comments below.

Not acceptable. The users need guidance about how to start the session 
as humans, not just which media to enable.
If the answerer starts with the last resort language/modality but can do 
the preferred, the caller may get the wrong impression that the last 
resort needs to be used and there will be a long confusion before they 
sort out the most efficient way to communicate.

There is also a need to differentiate this case when just one 
language/modality is needed from the cases when both language/modalities 
are required.

And it is a way for the answering part who happen to have a terminal 
only supporting the caller's last resort that it is ok to answer with 
that. The caller would not to announce the capability if it would mean 
that it was on same prerference level as the preferred language /modality.

Conclusion:  Priority declaration across m-lines is required.
> case outcome is that unused media streams are established.

Not acceptable. see reasoning above.  Maybe absolute preference is not 
the correct requirement. Preference level regardless of m-line is maybe 
more appropriate description.
Not acceptable.
The text answer path is very strongly preferred.
The voice answer path is just appreciated.
The answering part should not just aswer by voice phone and ignore the 
text need.
Coding of a clear preference for getting the text included  is needed.
Yes maybe. This is rather an indication that the current * parameter is 
nearly always needed, and should possibly be the default.
Not acceptable.
It is possible only in the simple case when only one language in each 
direction is declared.
But if the caller want to indicate:
I strongly want to speak, and get text back, but I can also as the last 
resort type and get text back, then it is important to get the preferred 
alternative combination on high priority.
Not acceptable. They are needed.
agreed
> Typo in line #5: "allow give" should choose one.
agreed. Delete "allow".
> Delete "as well as an indication of absolute preference" from second 
Not acceptable.  but may be rephrased everywhere to "level of preference 
across all media"
> Delete "seem to be needed" from end of last sentence of second paragraph.
Agreed   ( but the beginning of the sentence need adjustments. I take 
that separately.)
Privacy is usually discussed in the security section. It can be made a 
subsection.
Regards

Gunnar

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

---

From: Randall Gellens <[email-masked]>
Date: Thu, 7 Apr 2016 18:47:18 -0700

At 12:26 AM +0200 4/8/16, Gunnar Hellström wrote:

>  Randall,
>  Sadly very few of your change proposals for the 
> use case document matches my view of the needs 
> we have and the requirements they raise.

Hi Gunnar,

Yes, this is the core of the disagreement.

Please see in-line.

>  Not acceptable. The users need guidance about 
> how to start the session as humans, not just 
> which media to enable.
>  If the answerer starts with the last resort 
> language/modality but can do the preferred, the 
> caller may get the wrong impression that the 
> last resort needs to be used and there will be 
> a long confusion before they sort out the most 
> efficient way to communicate.

If all media are set up, then the caller can use 
or not use any of them.  (Just as, if during 
mid-call additional media are enabled, then the 
caller can start using them.)

>
>  There is also a need to differentiate this case 
> when just one language/modality is needed from 
> the cases when both language/modalities are 
> required.

If the caller requests both, and both are 
established, then a caller who wants both is 
happy, and a caller who only needed one can 
ignore the other and also be happy.
>
>  And it is a way for the answering part who 
> happen to have a terminal only supporting the 
> caller's last resort that it is ok to answer 
> with that. The caller would not to announce the 
> capability if it would mean that it was on same 
> prerference level as the preferred language 
> /modality.

If it is the caller who knows which media are 
required, then the caller can use any that were 
established.  If the caller's device knows, then 
the caller's device could always close the unused 
media with a re-INVITE and not bother announcing 
them to the caller.

>>  Should be deleted.  An absolute preference is 
>> not needed.  The worst case outcome is that 
>> unused media streams are established.
>
>  Not acceptable. see reasoning above.  Maybe 
> absolute preference is not the correct 
> requirement. Preference level regardless of 
> m-line is maybe more appropriate description.
>>
>>  ----------
>  The answering part should not just aswer by 
> voice phone and ignore the text need.

The caller asks for both text and voice.  If both 
are established, the caller is happy.  Since text 
is listed first, it is possible that the answerer 
could in theory (but not likely in practice) only 
set up text and not voice.  The caller's needs 
are met either way.

>  Yes maybe. This is rather an indication that 
> the current * parameter is nearly always 
> needed, and should possibly be the default.
>>
>>  ----------
>>  In use case 2.6, change:
>>
>>  OLD:
>  It is possible only in the simple case when 
> only one language in each direction is declared.

It works in other cases as well, with the 
possible downside of establishing unused media 
streams.

>  I strongly want to speak, and get text back, 
> but I can also as the last resort type and get 
> text back, then it is important to get the 
> preferred alternative combination on high 
> priority.

Worst case is all media streams are established 
(audio with some language from caller to 
answerer, plus text from answerer to caller, plus 
text two-ways) and the caller speaks using the 
audio stream and the answerer types using one of 
the text streams, and the other text stream is 
not used.  What's important is that the call 
succeeded and the caller and answerer can 
communicate.

>  Not acceptable. They are needed.

I am not convinced.  So far, all use cases will 
result in a successful call with caller and 
answerer able to communicate.

>>  Typo in line #5: "allow give" should choose one.

Editor's choice which word to use.  I don't care.

>  Not acceptable.  but may be rephrased 
> everywhere to "level of preference across all 
> media"

I do not agree that this phrase is needed either.

>  Agreed   ( but the beginning of the sentence 
> need adjustments. I take that separately.)
>>
>>  ----------
>>  Section 4: I think this is more properly a 
>> privacy consideration, so consider adding a 
>> privacy considerations section with this text, 
>> and changing the security considerations to 
>> say something such as "no additional security 
>> risks have been identified by the ability to 
>> indicate language."
>  Privacy is usually discussed in the security 
> section. It can be made a subsection.

It's become more common to call out privacy in 
its own section, as a way to highlight privacy 
issues that are separate from security issues. 
Sometimes the issues are closely related, in 
which case discussing them in the security 
considerations section is the right answer.  That 
doesn't seem to be the case here.

-------------- Randomly selected tag: ---------------
In Germany they came first for the Communists, and I didn't speak up
because I wasn't a Communist.  Then they came for the Jews, and I
didn't speak up because I wasn't a Jew.  They came for the trade
unionists, I didn't speak up because I wasn't a trade unionist.  Then
they came for Catholics, and I didn't speak up because I was a
Protestant.  Then they came for me, and by that time no one was left
to speak up.                                        --Martin Niemoell