Re: [Slim] [slim] #9 (negotiating-human-language): Attribute specifications following the layout required by RFC4566bis

[Randall Gellens <[e-mail]>]

Hi Gunnar,

These create a complex mechanism that goes beyond 
what we agreed to do for the initial version. 
I'm happy to work with you on these mechanisms or 
something else for a revision or extension.

--Randy

At 9:33 PM +0200 8/12/16, Gunnar Hellström wrote:

>  Den 2016-08-09 kl. 15:06, skrev Brian Rosen:
>>  I agree that we need to conform to the 4566 template.
>>
>>  I don't agree with changing the definition of the attribute.
>  I find it hard to see that you do not agree in 
> any of the proposed changes in the definitions.
>  Here they are in a numbered list.
>
>  1. Move the session level parameter about 
> rejecting or connecting the call in case of no 
> language match to session level. There is no 
> logically correct place for this parameter in 
> the media level attributes.
>
>  2. Revert the default value of the rejecting or 
> connecting the call at no match to be 
> connecting. That matches the scope of the 
> parameter better, and is in line with the 
> discussion in the mail list.
>
>  3. Add a value "improve" to the session level 
> attribute, with the meaning "I can improve 
> language matches by introduction of means not 
> initially indicated. ( such as a caller not 
> invoking a relay service initially, but after 
> the answer when it shows that a relay service 
> is needed. )
>
>  4. Introduce a modality parameter in the 
> humintlang-send and humintlang-recv attribute 
> values. Default values handle most cases, but 
> there are cases when an explicit value is 
> needed, because it is not evident from the 
> m-line and the language tag what modality 
> indicated. This is especially true for 
> m=application cases.
>  (A complex alternative would be to specify all 
> cases we know now explicitly of language use 
> where it is not explicit by the mime type and 
> the language tag what modality is intended, but 
> I think that is too inflexible. )
>
>  5. Combine all languages for one media, 
> modality and direction in a space separated 
> list as value to one humintlang-send or 
> humintlang-recv attribute. That matches the 
> format of the SIP Accept-Language field value.
>  It also matches the logic of only indicating one highest favoured language.
>  It would be possible to have only one language 
> per humintlang-send or humintlang-recv 
> attribute and include multiple attributes per 
> media and direction. But then the syntax of the 
> most favoured parameter gets less logical. 
> Therefore I propose the changed attribute 
> syntax.
>
>  6. Introduce a mark for most favoured media, 
> meaning that the first language in the value 
> list of the corresponding attribute is the most 
> favoured for that direction. This can enable 
> the negotiation to result in good decisions so 
> that language exchange gets efficient. Without 
> it, the start of the call will be in randomly 
> selected modality and language among a set with 
> undefined relative favour, causing problems to 
> correct the modality and language when it gets 
> initially wrong.
>
>  7. Allow indication of up to two highest 
> favoured modalities per direction, or one 
> highest favoured and one complementing, so that 
> good decisions can be made.
>  That enables specifying the needs behind the 
> use of some common types of relay services or 
> favoured behavior of the other party. Without 
> this, there are calls that will not be answered 
> in the most efficient way, instead causing 
> confusion and delay.
>
>
>  Regards
>
>  Gunnar
>
>
>
>>
>>  Brian
>>
>>
>>>  On Aug 9, 2016, at 4:49 AM, slim issue 
>>> tracker <[e-mail]> wrote:
>>>
>>>  #9: Attribute specifications following the layout required by RFC4566bis
>>>
>>>  The attribute specifications need to be more formal than in the current
>>>  draft (-04 )
>>>
>>>  The following is required from attribute specifications according to RFC
>>>  4566bis, section 8.2.4.1:
>>>
>>>
>>>
>>>  "New attribute registrations are accepted according to the
>>>      "Specification Required" policy of [RFC5226], provided that the
>>>      specification includes the following information:
>>>
>>>      o  Contact Name.
>>>
>>>      o  Contact Email Address.
>>>
>>>      o  Attribute Name: The name of the attribute that will appear in
>>>         SDP).  This MUST conform to the definition of <att-field>.
>>>
>>>      o  Attribute Syntax: For a value attribute (see clause 5.13), an ABNF
>>>         definition of the attribute value <att-value> syntax (See
>>>         Section Section 9) MUST be provided.  The syntax MUST follow the
>>>         rule form as per Section 2.2 of [RFC5234].  This SHALL define the
>>>         allowable values that the attribute might take.  It MAY also
>>>         define an extension method for the addition of future values.  For
>>>         a property attribute, the ABNF definition is omitted as the
>>>         property attribute takes no values.
>>>
>>>      o  Attribute Semantics: For a value attribute, a semantic description
>>>         of the values that the attribute might take MUST be provided.  The
>>>         usage of a property attribute is described under purpose below.
>>>
>>>      o  Attribute Value: The name of an ABNF syntax rule defining the
>>>         syntax of the value.  Absence of a rule name indicates that the
>>>         attribute takes no values.  Enclosing the rule name in "[" and "]"
>>>         indicates that a value is optional.
>>>
>>>      o  Usage Level: Usage level(s) of the attribute.  One or more of:
>>>         session, media, source, dcsa, dcsa(subprotocol).  For a definition
>>>         of source level attributes, see [RFC5576].  For a definition of
>>>         dcsa attributes see: [I-D.ietf-mmusic-data-channel-sdpneg].
>>>
>>>      o  Charset Dependent: Whether the attribute value is subject to the
>>>         charset attribute or not (Yes/No).
>>>
>>>      o  Purpose: An explanation of the purpose and usage of the attribute.
>>>
>>>      o  O/A Procedures: Offer/Answer procedures as explained in [RFC3264].
>>>
>>>      o  Mux Category: Indication of which multiplexing "category"
>>>         [I-D.ietf-mmusic-sdp-mux-attributes] an attribute is associated
>>>         with.
>>>
>>>      o  Reference: A reference to the specification defining the
>>>         attribute.
>>>  "
>>>
>>>
>>>  ---------------------------------------------------------------
>>>  Change. Add chapters on the attributes in the format described in
>>>  RFC4566bis, section 8.2.4.1
>>>
>>>  Some changes are also needed in the earlier text in the draft to align
>>>  with these attribute specifications.
>>>  --------------------------------------------------------------------
>>>
>>>
>>>  x. Specification of the "humintlang-disposition" attribute
>>>
>>>      o  Contact Name.
>>>      XXXXXXXXXXXXXXXXXXXXXXXXXXXX
>>>
>>>      o  Contact Email Address.
>>>      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>>>
>>>      o  Attribute Name:
>>>      humintlang-disposition
>>>
>>>      o  Attribute Syntax:
>>>      humintlang-disposition = "a=humintlang-disposition" HCOLON disposition
>>>
>>>      o  Attribute Semantics:
>>>      If no match is possible, the value of the "humintlang-disposition"
>>>  session level attribute should be interrogated by the answering party for
>>>  the decision about how to handle the call. If the value is "reject", then
>>>  the call MAY be rejected. There may however be application reasons to
>>>  connect the call anyway. In that case the the humintlang-send actually
>>>  intended to be used and the humintlang-recv value of the most likely
>>>  combination to be initially used in the call shoud be included in the
>>>  answer. Emergency calls should not be rejected because of language
>>>  mismatch reasons.
>>>
>>>           If the value of the "humintlang-disposition" session level
>>>  attribute is "improve", then the party who inserted that value has some
>>>  means to improve the match e.g. by adding an interpreting agent, e.g. a
>>>  relay service. An answering party detecting the "improve" value may then
>>>  connect the call, insert all its non-matching humintlang-send and
>>>  humintlang-recv values and look forward to receiving new sdp with possibly
>>>  better match. The offering party, or a service provider along the call
>>>  path, detecting in the answer that the media/modality/direction/language
>>>  indications did not match, may act to improve the match, e.g. by adding an
>>>  interpreting agent, e.g. a relay service, to arrange for a better match.
>>>  The parties involved in the call shall be informed about the result of
>>>  such actions by new sdp with new values in the humintlang attributes. The
>>>  mechanisms for such detection, decision and modifications of the call are
>>>  out of scope for this specification. The ability to use such mechanisms
>>>  shall be indicated by the value "improve" in the "humintlang-disposition"
>>>  session attribute.
>>>
>>>           When the value of the "humintlang-disposition" is "connect" (that
>>>  is also the default value), then the call should be connected even without
>>>  matching language/modality/direction indications. In that case the the
>>>  humintlang-send actually intended to be used and the humintlang-recv value
>>>  of the most likely combination to be initially used in the call shoud be
>>>  included in the answer. The connected parties may use in-band actions to
>>>  figure out if they have any human language communication means that fulfil
>>>  the intentions of the call.
>>>
>>>      o  Attribute Value:
>>>      disposition = "reject"/"complete"/"improve"/disposition-extension
>>>      disposition-extension = token
>>>      The value "complete" is default.
>>>
>>>      o  Usage Level:
>>>      session
>>>
>>>      o  Charset Dependent: No.
>>>
>>>      o  Purpose:
>>>      The attribute specifies how to handle the call when no language or
>>>  modality match is found.
>>>
>>>
>>>      o  O/A Procedures:
>>>           If no match is possible, the value of the "humintlang-disposition"
>>>  session level attribute should be interrogated by the answering party for
>>>  the decision about how to handle the call. If the value is "reject", then
>>>  the call MAY be rejected. There may however be application reasons to
>>>  connect the call anyway. In that case the the humintlang-send actually
>>>  intended to be used and the humintlang-recv value of the most likely
>>>  combination to be initially used in the call shoud be included in the
>>>  answer. Emergency calls should not be rejected because of language
>>>  mismatch reasons.
>>>
>>>           An answering party detecting the "improve" value may then connect
>>>  the call, insert all its non-matching humintlang-send and humintlang-recv
>>>  values and look forward to receiving new sdp with possibly better match.
>>>  The offering party, or a service provider along the call path, detecting
>>>  in the answer that the media/modality/direction/language indications did
>>>  not match, may act to improve the match, e.g. by adding an interpreting
>>>  agent, e.g. a relay service, to arrange for a better match. The parties
>>>  involved in the call shall be informed about the result of such actions by
>>>  new sdp with new values in the humintlang attributes.
>>>
>>>           When the value of the "humintlang-disposition" is "connect" (that
>>>  is also the default value), then the call should be connected even without
>>>  matching language/modality/direction indications. In that case the the
>>>  humintlang-send actually intended to be used and the humintlang-recv value
>>>  of the most likely combination to be initially used in the call shoud be
>>>  included in the answer.
>>>
>>>      o  Mux Category:
>>>      NORMAL
>>>
>>>      o  Reference:
>>>
>>>             draft-ietf-slim-human-language-negotiation
>>>
>>>      o  Example:
>>>      See the example for the humintlang-send and humintlang-recv attributes.
>>>
>>>
>>>
>>>  Y. Specification of the humintlang-send and humintlang-recv attributes
>>>
>>>      o  Contact Name.
>>>      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>>>
>>>      o  Contact Email Address.
>>>      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>>>
>>>      o  Attribute Name:
>>>      humintlang-recv
>>>
>>>      humintlang-send
>>>
>>>
>>>
>>>      o  Attribute Syntax:
>>>           humintlang-send  =  "a=humintlang-send" HCOLON [humintlang-value]
>>>
>>>           humintlang-recv  =  "a=humintlang-recv" HCOLON [humintlang-value]
>>>
>>>           When used without language parameter, the humintlang-send and
>>>  humntlang-recv attribute indicates modality and direction for use with the
>>>  default language of the area and media or media/subprotocol.
>>>
>>>
>>>      o  Attribute Semantics:
>>>      In order to successfully start a call, the parties need to be aware of
>>>  which language capabilities were negotiated, and also which modality the
>>>  parties prefer to use. A call can start without hesitation and be
>>>  conducted smoothly only when answered with the modality and language that
>>>  best matches the most favoured combinations by the caller. There is a
>>>  tendency among call participants to continue using the modality first used
>>>  in a call, even if that is not the most favoured modality. The call
>>>  participants usually want to communicate about the topic of the call, and
>>>  not about how the call will be performed. Therefore, a mechanism is
>>>  provided for indication of most preferred modality/modalities of the call
>>>  participants together with the language attributes.
>>>
>>>           The humintlang-send attribute indicates modality and language
>>>  preferences for transmission from the indicating party.
>>>           The humintlang-recv attribute indicates modality and language
>>>  preferences for reception by the indicating party.
>>>
>>>           The mechanism provides a "favoured" modality parameter that MAY be
>>>  included in the "humintlang-send" and "humintlang-recv" attribute values
>>>  on media level. The "favoured" modality parameter is a keyword parameter
>>>  with the name "favoured" and values "most" and "complement".
>>>
>>>           The "favoured" parameter is intended to be optionally included
>>>  once for each combination of media, modality and direction of language.
>>>  The indication is intended to carry the information that the indicated
>>>  combination is the highest favoured alternative if the value is "most",
>>>  and is a highly favoured complement to the most favoured modality in
>>>  another media description if the value is "complement". The value "most"
>>>  is allowed for more than one media/modality/direction combination for
>>>  cases when it is essential for the indicating party to use more than one
>>>  modality in the same direction. The "complement" value SHOULD not be used
>>>  without any "most" value in the sdp, and should only be used for cases
>>>  when the modality it is used with is supposed to be used for language
>>>  transfer simultanously with the corresponding most favoured modality.
>>>
>>>           The language parameter is an optional list of languages that the
>>>  indicating party is prepared to use in the indicated media, modality and
>>>  direction. The list is a whitespace separated list of language tags
>>>  arranged in preference order, with highest preferred first.
>>>
>>>
>>>      o  Attribute Value:
>>>
>>>       humintlang-value =[*humintlang-param][*language]
>>>           humintlang-param =  [modality][favoured]
>>>           modality = "modality=" ("spoken"/"signed"/"written"/modality-
>>>  extension)
>>>           The value "spoken" is default for audio media.
>>>           The value "signed" is default for video media except when used
>>>  with a spoken or written language.
>>>           The value "spoken" is default for video media when used with
>>>  spoken language.
>>>           The value "written" is default for text media
>>>           favoured= "favoured="("most"/"complement")
>>>           modality-extension = token
>>>           Modalities can be extended with further modalities and assigned
>>>  values indicated
>>>           language         =  Language-Tag
>>>           where Language-Tag is defined in RFC 5646, Section 2.1.
>>>
>>>
>>>      o  Usage Level:
>>>       media, dcsa(subprotocol).
>>>           dcsa(T140) can be indicated to carry text modality.
>>>
>>>      o  Charset Dependent: No
>>>
>>>      o  Purpose:
>>>       In order to successfully start a call, the parties need to be aware of
>>>  which language capabilities were negotiated, and also which modality the
>>>  parties prefer to use. A call can start without hesitation and be
>>>  conducted smoothly only when answered with the modality and language that
>>>  best matches the most favoured combinations by the caller. The attributes
>>>  are intended to carry the information about supported and favoured
>>>  languages and modalities between the communicating parties.
>>>
>>>      o  O/A Procedures:
>>>           Offering parties who strongly favour specific ways to communicate
>>>  by language are expected to indicate these ways using the humintlang-send
>>>  or humintlang-recv attributes with the "favoured=most" parameter on the
>>>  most favoured media/modality/direction combination(s). A "favoured=most"
>>>  indication may be included for all media/modality/direction combinations
>>>  that are eagerly wanted together (usually one or two per direction). If
>>>  one media/modality/direction is wanted together with a most favoured
>>>  combination but with lower urgency, then the "favoured=complement" should
>>>  be indicated (usually none or one per direction). Other
>>>  media/modality/direction combinations SHALL be left without the "favoured"
>>>  indication.
>>>
>>>           When only one language indication for a direction in the whole sdp
>>>  is indicated, it is regarded to be the most favoured language for the
>>>  indicated direction.
>>>
>>>           The answering party is expected to try to start the call in the
>>>  media/modality/direction combinations indicated with favoured parameters
>>>  in the languages highest preferred by the offering party. What the
>>>  answering party does if no match is possible for the highest favoured
>>>  combinations, or if no combinations are marked as highest favoured is
>>>  application dependent, and depending on the "humintlang-disposition"
>>>  session level attribute. Answering parties may select other than the
>>>  highest favoured combinations of the offer or add an interpreting agent,
>>>  e.g. a relay service to arrange for a better match in languages and
>>>  modalities in the call. The media/modalities/directions/languages selected
>>>  for language communication by the answering party shall be indicated by
>>>  "humintlang-send" and "humintlang-recv" attributes in the answer. If no
>>>  match is possible, the value of the "humintlang-disposition" session level
>>>  attribute should be interrogated by the answering party for the decision
>>>  about how to handle the call. If the value is "reject", then the call MAY
>>>  be rejected. There may however be application reasons to connect the call
>>>  anyway. In that case the the humintlang-send actually intended to be used
>>>  and the humintlang-recv value of the most likely combination to be
>>>  initially used in the call shoud be included in the answer. Emergency
>>>  calls should not be rejected because of language mismatch reasons.    The
>>>  mechanism provides a "favoured" modality parameter that MAY be included in
>>>  the "humintlang-send" and "humintlang-recv" attribute values on media
>>>  level. The "favoured" modality parameter is a keyword parameter with the
>>>  name "favoured" and values "most" and "complement".
>>>
>>>           This parameter is intended to be optionally included once for each
>>>  combination of media, modality and direction of language. The indication
>>>  is intended to carry the information that the indicated     combination is
>>>  the highest favoured alternative if the value is "most", and is a highly
>>>  favoured complement to the most favoured modality in another media
>>>  description if the value is "complement". The value "most" is allowed for
>>>  more than one media/modality/direction combination for cases when it is
>>>  essential for the indicating party to use more than one modality in the
>>>  same direction. The "complement" value SHOULD not be used without any
>>>  "most" value in the sdp, and should only be used for cases when the
>>>  modality it is used with is supposed to be used for language transfer
>>>  simultanously with the corresponding most favoured modality.
>>>
>>>           The offering party is expected to include all supported languages
>>>  in the offer. The answering party who can match sufficient
>>>  languages/modalities and directions of the offering party, is expected to
>>>  include in the answer the languages selected for initial use in the call
>>>  and include the "favoured=most" parameter for the modalities that the call
>>>  is intended to start with. If no match was found, then all supported
>>>  languages should be included and the "favoured=most" parameter for the
>>>  modalities that the call is intended to start with.
>>>
>>>      o  Mux Category:
>>>      NORMAL
>>>
>>>      o  Reference:
>>>           draft-ietf-slim-human-language-negotiation
>>>
>>>      o  Examples: (with shortened surrounding sdp)
>>>
>>>      Offer:
>>>      s=-
>>>      a=humintlang-disposition: connect
>>>      m=audio 34056 RTP/AVP 8
>>>      a=humintlang-send: modality=spoken favoured=most en fr
>>>      m=video 36068 RTP/AVP 34
>>>      m=text 35072 RTP/AVP 102
>>>      a=humintlang-recv: modality=written favoured=most en fr
>>>      a=humintlang-send: modality=written en fr
>>>
>>>      Answer
>>>      s=-
>>>      a=humintlang-disposition: connect
>>>      m=audio 34066 RTP/AVP 8
>>>      a=humintlang-recv: modality=spoken favoured=most en
>>>      m=video 0 RTP/AVP 34
>>>      m=text 35092 RTP/AVP 102
>>>      a=humintlang-send: modality=written favoured=most en
>>>
>>>
>>>  This sdp exchange indicates that the offering party wants the call to be
>>>  connected regardless of the outcome of the negotiation, and that the most
>>>  favoured modality and language is to speak English, but speaking French is
>>>  also possible.
>>>  The offering party also offers video, but with no intention to use it for
>>>  language.
>>>  The incoming language is preferred in written real-time text form.
>>>  The offering party can accept to send English or French text if the other
>>>  party is not capable of receiving spoken English.
>>>
>>>  The answering party accepts to connect the call, and use the favoured
>>>  modalities in English. No video capability is available, so the video
>>>  offer is rejected, but the call connected, and the answering party can
>>>  start with a written text greeting and expect to get spoken response.
>>>
>>>  Note: Both the humintlang-disposition value "connect" and the modalities
>>>  indicated are the default values, so they could in this case have been
>>>  left out with the same result.
>>>
>>>  --
>>>  -------------------------------------+-------------------------------------
>>>  Reporter:                           |      Owner:  draft-ietf-slim-
>>>    [e-mail]        |  [e-mail]
>>>       Type:  defect                   |     Status:  new
>>>  Priority:  major                    |  Milestone:
>>>  Component:  negotiating-human-       |    Version:
>>>    language                           |   Keywords:  Attribute
>>>  Severity:  -                        |
>>>  -------------------------------------+-------------------------------------
>>>
>>>  Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/9>
>>>  slim <https://tools.ietf.org/slim/>
>>>
>>>  _______________________________________________
>>>  SLIM mailing list
>>>  [e-mail]
>>>  https://www.ietf.org/mailman/listinfo/slim
>
>  --
>  -----------------------------------------
>  Gunnar Hellström
>  Omnitor
>  [e-mail]
>  [phone]


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
It has been observed that one's nose is never so happy as when
it is thrust into the affairs of another, from which some
physiologists have drawn the inference that the nose is devoid
of the sense of smell.
        --Ambrose Bierce, "The Devil's Dictionary"