Re: [Slim] draft-hellstrom-slim-simultaneous-modalities & modalitypref

[Gunnar Hellström <[e-mail]>]

Paul,  thanks for reviewing and commenting,

Den 2017-06-07 kl. 21:43, skrev Paul Kyzivat:
> I did a quick review of these documents. My feeling is that these have 
> moved to quickly to specific solution syntax without first sorting out 
> exactly what the needs are. I am sympathetic to what I think the goals 
> are, but am concerned that the proposed solutions are not ideal.
<GH>During the lengthy discussions about the functionality that these 
two drafts add to the human-language-negotiation draft, low complexity 
has always been a strong argument for keeping notation very simple and 
rather make functionality shortcuts than allow parameters that add 
complexity. That explains why the proposals look as they do, but of 
course decisions can be made to change this approach.
>
>
> For instance, simultaneous-modalities indicates the languages of the 
> source form and the transformed form. But it does not indicate 
> precisely which media stream contains the source form. I guess the 
> assumption is that there will only be one other media stream with the 
> appropriate language indication. But that is just an assumption. It 
> may well apply in a number of common cases, but I'm sure we can come 
> up with more complex cases where that isn't true.
<GH>I think it will be straightforward to find the original. It must be 
in another media than the one with the "t" extension, because the 
human-language-negotiation draft does not allow more than one language 
negotiated per stream. If the original is a sign language, then it is to 
be found in the video stream. If it is not a sign language the original 
is to be searched in the audio specification if the "t"-extended 
language is in a written media and the opposite.  Only if we start using 
more than one media stream per media we get more complications to find 
the original. But it is still doable and we have not at all discussed 
multiple streams of the same media kind for our base draft.
> ISTM that it would be better to come up with a syntax that explicitly 
> links the source and transformed media streams. (E.g. a new usage of 
> the grouping framework.)
<GH>We have discussed the use of the grouping framework a long time ago, 
and it was not a popular solution because of the complexity it causes.

An alternative I have proposed is q-values with the extra rule that 
q-values less than 0.1 apart implies request for simultaneous 
languages/modality. But q-values have been rejected.
>
>
> In the modalitypref document if find the semantics fuzzy, and the 
> relationship of the use of "*" for this to be even more fuzzy when 
> related to its use in draft-ietf-slim-negotiating-human-language. For 
> instance, I see a potential conflict between need to express degree of 
> competence with a modality with preference for that modality. It may 
> be that those should be handles as two distinct indicators. Further 
> discussion is needed.
<GH>I think it is often the degree of competence that causes the grade 
of preference. But sometimes it may be the
feasability of using a modality in the conversational setting, e.g. a 
noisy place.
The current coding with the * makes a shortcut in that all languages 
specified for that media gets the same preference. So the following 
reasoning cannot be coded: "I can use spoken English well, but my French 
is so bad that I prefer to use that in written modality" .
I think the preference put on the modality rather than on language level 
is a good and realistic simplification.  I agree that the co-use of the 
asterisk with the preference for non-denial of the session is not 
elegant. But its effects are mild and described in the 
modality-preference draft.

Alternatives are q-values with scope over the whole SDP or separate 
a=modalitypreference:HI  attributes.  Q-value proposals have been rejected.

Thanks,
Gunnar
>
>     Thanks,
>     Paul
>
> _______________________________________________
> SLIM mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]