Re: [Gen-art] [Slim] Review of draft-ietf-slim-negotiating-human-language-06

[Randall Gellens <[e-mail]>]

At 10:42 AM -0500 2/22/17, Dale R. Worley wrote:

>  Gunnar Hellström <[e-mail]> writes:
>>>>   A. Call failure
>>>>
>>>>   If a call fails due to no available language match, in what way(s)
>>>>   does it fail?  Section 5.3 says
>>>>
>>>>      If such an offer is received, the receiver MAY
>>>>      reject the media, ignore the language specified, or attempt to
>>>>      interpret the intent
>>>>
>>>>   But I suspect it's also allowed for the UAS to fail the call at the
>>>>   SIP level.  Whether or not that is allowed (or at least envisioned)
>>>>   should be described.  And what response code(s)/warn-code(s) should
>>>>   be used for that?
>>>
>>>  The text you quote has been deleted.  The draft does not mandate if
>>>  the call should proceed or fail if there is no language match
>>>  possible, although the draft does provide an optional mechanism to
>>>  indicate the caller's preference that the call not fail, and the draft
>>>  does mention that in the emergency services case, the call will likely
>>>  proceed, but that's a matter of policy not protocol.
>>
>>  You may have a version where it is proposed that the text is deleted. We
>>  need to see that new text and agree if it was good to delete it.
>>
>>  There are more places in the draft where failing the call is mentioned,
>>  so the question about how it is failed is relevant anyway. A 603 Decline
>>  from the proxy would likely be the natural way to fail the call when it
>>  is because of lack of matching languages. But I do not see any natural
>>  way for an addressed UA to signal this.
>
>  I would argue strongly against using a 6xx response, as the defined
>  effect of those is to make the call fail all the way back to the
>  caller, rather than allowing alternative forks of the call to possibly
>  succeed.  The way to handle a call that *this* proxy can't route due to
>  language incompatibility is a 4xx response.
>
>  My question wasn't for the draft to be prescriptive on this issue (and
>  that seems to align with what the WG/authors intend), but to provide
>  implementation advice, best practices as it were -- There are a lot 4xx
>  responses available, and if you don't read their descriptions carefully,
>  it can be easy to choose one with the wrong semantics.  E.g., a 415
>  response is "Unsupported Media Type", but it's not for unsupported media
>  in the *session* (i.e., the SDP), it's for unsupported media in the
>  *INVITE body* (i.e., you can't process application/sdp).
>
>  OK, here it is:  RFC 3261 section 13.3.1.3:
>
>     A UAS rejecting an offer contained in an INVITE SHOULD return a 488
>     (Not Acceptable Here) response.  Such a response SHOULD include a
>     Warning header field value explaining why the offer was rejected.
>
>  section 21.4.26:
>
>  21.4.26 488 Not Acceptable Here
>
>     The response has the same meaning as 606 (Not Acceptable), but only
>     applies to the specific resource addressed by the Request-URI and the
>     request may succeed elsewhere.
>
>     A message body containing a description of media capabilities MAY be
>     present in the response, which is formatted according to the Accept
>     header field in the INVITE (or application/sdp if not present), the
>     same as a message body in a 200 (OK) response to an OPTIONS request.
>
>  and section 21.6.4:
>
>  21.6.4 606 Not Acceptable
>
>     The user's agent was contacted successfully but some aspects of the
>     session description such as the requested media, bandwidth, or
>     addressing style were not acceptable.
>
>     A 606 (Not Acceptable) response means that the user wishes to
>     communicate, but cannot adequately support the session described.
>     The 606 (Not Acceptable) response MAY contain a list of reasons in a
>     Warning header field describing why the session described cannot be
>     supported.  Warning reason codes are listed in Section 20.43.
>
>  And my memory was correct; a Warning header is appropriate in a 488
>  response.  Section 20.43 gives the details; it looks like a warn-code in
>  the range 390-398 is appropriate, or perhaps 300-329.  It seems like the
>  choice should be either 308 or 390, the first available codes in those
>  ranges.  And the ideal message text would contain the list of compatible
>  languages:
>
>      Warning: 308 proxy.example.com "Supported languages are: es, en"
>
>  The registration would be something like:
>
>      308 Incompatible language specification:  No requested      [this RFC]
>          language is supported and offerer requested failure.
>          The text should include the list of supported languages.

Thanks, Dale.  It seems that it would be useful 
for the draft to suggest (not require) that a 
session rejected due to lack of 
mutually-supported languages use 488 or 606, and 
also include a Warning header field with the 
suggested 308 code that the draft would register.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
We are what we repeatedly do. Excellence, then, is not an act but a habit.
                                --Aristotle