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

[Paul Kyzivat <[e-mail]>]

On 6/7/17 4:44 PM, Gunnar Hellström wrote:
> 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.

AFAIK we have not discussed it because there has been no need to. Not 
discussing doesn't mean that such usage has been excluded or that it 
needs more consideration before it can be used.

But once we start linking two streams together then it gets important. 
Leaving it to ad hoc implementation without specification is asking for 
trouble.

>> 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.

I only threw that out as one possibility. But it directly fits the use 
case, and whatever complexity it brings is mitigated because it is an 
existing mechanism.

> 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.

That addresses an entirely different problem.

>> 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.

ISTM that the rejections were because these were perceived as making the 
base mechanism more complex. Once this is split off as a separate 
mechanism then I think we get to revisit those discussions.

	Thanks,
	Paul