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