Subject: Re: [Slim] Last Call: <draft-ietf-slim-negotiating-human-language-06.txt> (Negotiating Human Language in Real-Time Communications) to Proposed Standard

From: "Doug Ewell" <[email-masked]>
Date: Mon, 13 Feb 2017 10:53:55 -0700

Gunnar Hellström wrote:

> 5. Make use of the asterisk modifier on media level with session scope
> also for media level purposes 
>
> The asterisk modifier optionally appended on attribute values has in
> the original -06 draft only a session effect. It is specified to
> indicate if the call should be rejected or not if languages do not
> match. It can be appended to any humintlang attribute in the whole SDP
> without any change in effect. This independancy of placement indicates
> that it is wrongly placed. With the current definition, it should be a
> single separate session level attribute. Instead of specifying a
> separate session level attribute, it is proposed that the asterisk
> gets an expanded definition, so that its placement conveys meaning of
> value for the successful language negotiation. 
>
> It has been discussed in the SLIM WG that the specification lacks two
> functions, required by the specifications by other bodies who are
> waiting for the results of SLIM real-time work. (e.g. 3GPP TS 22.228
> and ETSI TR 103 201). 3GPP TS 22.228 requires "The system should be
> able to negotiate the user's desired language(s) and modalities, per
> media stream and/or session, in order of preference." Thus negotiation
> with preference indication within the session is required, not only
> within each media. ETSI TR 103 201 says "the Total Conversation user
> should be able to indicate the preferred method of communication for
> each direction of the session, so that the call-taker can be selected
> appropriately or an appropriate assisting service be invoked. " Saying
> "preferred" means that it should also be possible to indicate less
> preferred alternatives.

Gunnar, who participated extensively in the SLIM WG, appears to be
attempting to re-introduce a mechanism to indicate preference of
modality which was considered and rejected multiple times by the WG.

WG rejection of Gunnar's previous proposals to do this was based on
reluctance to try to solve this particular problem in the first version
of the spec, not on any of the specific mechanisms proposed to solve the
problem. Proposing a new or modified mechanism during IETF LC appears to
be an attempt to rehash an argument made, but not won, in the WG.

If this concerns a different issue, not merely a different way of
approaching it, please accept my apology and explain more clearly how it
is different.

--
Doug Ewell | Thornton, CO, US | ewellic.org

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Feb 2017 18:44:28 -0500

> approaching it, please accept my apology and explain more clearly how it

Gunnar's comment makes multiple points. You have highlighted one of them 
and ignored the others.

Even if you reject that one, consider the others. Notably:

- The text needs to be improved simply to properly explain and define 
the syntax related to the "*" as you intend to use it.

- the use of the "*" to indicate what it does is confusing. It is using 
a media level attribute "parameter" to signify a session level property. 
This has been brought up before, but simply rejected without (IMO) 
adequate justification. There seems to be some love for this particular 
syntax. ISTM that in part Gunnar is trying to adapt this syntax so that 
it both makes sense as a media-level attribute and simultaneously can 
satisfy the session level need that has been identified.

I accept the WG's decision not to address the "preference" issue. But 
this attachment to the "ugly child", if not addressed, invites getting 
IESG LC comments.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Mon, 13 Feb 2017 16:34:33 -0800

At 6:44 PM -0500 2/13/17, Paul Kyzivat wrote:

>  Gunnar's comment makes multiple points. You have highlighted one of 
> them and ignored the others.
>
>  - The text needs to be improved simply to properly explain and 
> define the syntax related to the "*" as you intend to use it.
>
>  - the use of the "*" to indicate what it does is confusing. It is 
> using a media level attribute "parameter" to signify a session 
> level property. This has been brought up before, but simply 
> rejected without (IMO) adequate justification. There seems to be 
> some love for this particular syntax. ISTM that in part Gunnar is 
> trying to adapt this syntax so that it both makes sense as a 
> media-level attribute and simultaneously can satisfy the session 
> level need that has been identified.
>
>  I accept the WG's decision not to address the "preference" issue. 
> But this attachment to the "ugly child", if not addressed, invites 
> getting IESG LC comments.

Hi Paul,

I don't believe the WG has any particular love for the asterisk 
syntax, but felt it was good enough for what's needed, and didn't see 
any benefit from anything else.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
You're most kind.  In fact, you're every kind.
          --Robert Preston in _Victor/Victoria_

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 15 Feb 2017 14:44:52 +0100

>> approaching it, please accept my apology and explain more clearly how it
You are partly right, but the new proposal concerns more issues and is 
suggested to be a simplified solution to them.

The proposal adds media level influence to the asterisk humintlang 
attribute value parameter. In draft -06 the asterisk is said to be a 
media level parameter. But it does not change any influence on media 
level depending on which media or humintlang attribute you append it to. 
It just has session influence. That clearly indicates that with the 
current definition, the asterisk parameter  is misplaced.

It can also be seen that it has quite vague and unprecise influence on 
the session level.

This is the essential part of section 5.3 where this parameter is defined:

"The mechanism for indicating this preference is that, in an offer, if
    the last character of any of the 'humintlang-recv' or 'humintlang-
    send' values is an asterisk, this indicates a request to not fail the
    call (similar to SIP Accept-Language syntax).  Either way, the called
    party MAY ignore this, e.g., for the emergency services use case, a
    PSAP will likely not fail the call."

So, the lack of the parameter everywhere in the SDP MAY be seen as a 
request to reject the call, but that request may be ignored.

The real effect of this parameter is therefore in fact a preference. In 
order to motivate its existence on the media level, I proposed the 
extension of its meaning with an influence depending on on which 
humintlang attribute(s) it is attached.
Since the lack of the parameter apparently indicates a stronger 
preference for getting the call through, I suggest that the placement of 
an asterisk on a specific humintlang attribute indicates lower 
preference for matching that language/modality/direction versus some 
other language/modality combination specified for the same direction.
The one who want the call rejected if the highest preferred 
language/modality could not be matched is likely less interested in 
providing lower preferenced alternatives, so the session influence can 
be maintained.

By that we both sort out inconsistencies with the use of the asterisk 
and add value to it that will enable much more satisfied users and more 
calls going through.
And the solution is simpler than all earlier proposals and much more 
simple than not acting on the addressed issues now.

My proposed wording is available in issue 5 in my initial mail from Feb 13.

  Regards
Gunnar

> using a media level attribute "parameter" to signify a session level 
> property. This has been brought up before, but simply rejected without 
> (IMO) adequate justification. There seems to be some love for this 
> particular syntax. ISTM that in part Gunnar is trying to adapt this 
> syntax so that it both makes sense as a media-level attribute and 
> simultaneously can satisfy the session level need that has been 
> identified.
>
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Feb 2017 12:13:50 -0500

On 2/13/17 7:34 PM, Randall Gellens wrote:

> Hi Paul,
>
> I don't believe the WG has any particular love for the asterisk syntax,
> but felt it was good enough for what's needed, and didn't see any
> benefit from anything else.

So, there is no love for the syntax, and the semantics associated with 
that syntax is at best muddy. It is specifying session level semantics 
as part of a media level attribute. IMO that isn't "good enough", and I 
also don't think "good enough" is the best criterion for advancement.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Wed, 15 Feb 2017 12:31:50 -0800

At 12:13 PM -0500 2/15/17, Paul Kyzivat wrote:

>  So, there is no love for the syntax, and the semantics associated 
> with that syntax is at best muddy. It is specifying session level 
> semantics as part of a media level attribute. IMO that isn't "good 
> enough", and I also don't think "good enough" is the best criterion 
> for advancement.

It serves an extremely weak and limited purpose, with no normative 
effects to using it or not.  Honestly, in my view if it was deleted 
from the draft it wouldn't make any difference.  I'm fine leaving it 
in or taking it out, but I do not see any point in introducing new 
mechanisms for such a small purpose, especially at this point in the 
draft's progress.

-------------- Randomly selected tag: ---------------
Those are my principles. If you don't like them I have others.
    --Groucho Marx