Re: [Slim] Last Call: <draft-ietf-slim-negotiating-human-language-06.txt> (Issue 5, section 5.3 )

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Den 2017-02-14 kl. 00:44, skrev Paul Kyzivat:

On 2/13/17 12:53 PM, Doug Ewell wrote:

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


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

_______________________________________________
SLIM mailing list
SLIM@xxxxxxxx
https://www.ietf.org/mailman/listinfo/slim

--
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@xxxxxxxxxx
+46 708 204 288




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]