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

From: "slim issue tracker" <[email-masked]>
Date: Tue, 09 Aug 2016 08:49:48 -0000

#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-
  [email-masked]        |  [email-masked]
     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/>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 9 Aug 2016 09:06:49 -0400

I agree that we need to conform to the 4566 template.

I don’t agree with changing the definition of the attribute.

Brian

> On Aug 9, 2016, at 4:49 AM, slim issue tracker <[email-masked]> wrote:
> 
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 12 Aug 2016 21:33:14 +0200

> 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

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

---

From: Randall Gellens <[email-masked]>
Date: Fri, 12 Aug 2016 13:14:40 -0700

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:

>>  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.
>  1. Move the session level parameter about 
> rejecting or connecting the call in case of no 
> language match to session level. There is no 
>  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 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 <[email-masked]> wrote:
>>>

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

---

From: Brian Rosen <[email-masked]>
Date: Fri, 12 Aug 2016 16:58:40 -0400

I agree.  Some detail below
> On Aug 12, 2016, at 4:14 PM, Randall Gellens <[email-masked]> wrote:
> 
> Hi Gunnar,
> 
I’m not worried about having this be at a media level.  The recipient can always reject the call for whatever reason it wants. The sender can always drop the call if it doesn’t like the result of negotiations.  t could easily construct use cases where what you want is media decisions, not session decisions (so, if you can’t give me English text, I don’t care if you can give me Spanish video, I want to fail the call).  It’s all advisory, and I’d prefer to keep it where it is.

>> discussion in the mail list.
I don’t really care about this.  Again, this is at best advisory, and either end can reject any time.  If you rely on defaults to get what you want, you deserve what you get.

>> the answer when it shows that a relay service 
I am strongly against doing this ever.  If you need to renegotiate, drop the call and try again, probably with some different path (i.e. with relay).

>> I think that is too inflexible. )
I am strongly against doing this ever.  I think it’s a bad idea.  

>> Therefore I propose the changed attribute 
I am strongly against doing this at this time.  I’m not sure if makes any sense, and I’d like to get some experience before we make decisions in this area.

>> correct the modality and language when it gets 
I really don’t think this is the best way to handle interactions between media, but regardless, at this time, I don’t think we should have mechanisms like this.

>> in the most efficient way, instead causing 
I am strongly against doing this at this time.  I doubt this will ever be the right answer, but at least now, I we had consensus not to have mechanisms like this in the document.

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 12 Aug 2016 23:14:31 +0200

Den 2016-08-12 kl. 22:14, skrev Randall Gellens:

> 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, can you please be explicit per change proposal. They are not 
really complex mechanisms. They are merely more explicit indications.

Some of the proposed changes are simply efforts to get what the draft 
want to say into an acceptable logic format. There may of course be 
better ways to express them.

There are some additions that could be sacrificed if we need to. ( e.g. 
the "improve" value of the humintlang-disposition), while the rest is 
needed to create some usability of the indications.
( have you tried yourself to go through an imagined offer-answer 
scenario with a multimedia call? You will discover that the situation is 
underspecified and will not give any of the guidance talked about in the 
introduction if you just use the indications from version -04, while by 
accepting most of the proposed changes, you will be better off for the 
most often appearing cases.)

Thanks
Gunnar

>>  1. Move the session level parameter about rejecting or connecting 
>> the call in case of no language match to session level. There is no 
>>  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 
>> 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.
>> 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. )
>>
>> 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 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.
>>
>> 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.
>>
>> direction, or one highest favoured and one complementing, so that 
>>  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
>>>
>>>

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 12 Aug 2016 23:24:53 +0200

> I agree.  Some detail below
Thanks Brian for being explicit.
I hope we can get good opportunities to discuss the points one by one.
One point that amazed me was that you did not want the modality 
parameter. How do you then propose to know where to find e.g. the 
written modality in an WebRTC sdp?

Thanks,
Gunnar

---

From: Brian Rosen <[email-masked]>
Date: Fri, 12 Aug 2016 17:28:31 -0400

I am not worried about applying a language to m=application.  I don’t think anyone will be confused.

Brian

> On Aug 12, 2016, at 5:24 PM, Gunnar Hellström <[email-masked]> wrote:
> 
> One point that amazed me was that you did not want the modality parameter. How do you then propose to know where to find e.g. the written modality in an WebRTC sdp?
> 
> Thanks,
> Gunnar
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>
> 
> -- 
> [email-masked] <mailto:[email-masked]>
> +46 708 204 288
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>

---

From: "slim issue tracker" <[email-masked]>
Date: Mon, 15 Aug 2016 16:59:47 -0000

Comment (by [email-masked]):

 Chairs: we should aim to conform to RFC4566bis. Randall: please take a
 look at RFC4566bis and make changes as you see fit.

  language                           |  Resolution:
 Keywords:  Attribute                |

Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/9#comment:1>
slim <https://tools.ietf.org/slim/>