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

[Gunnar Hellström <[e-mail]>]

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




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

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]