Subject: [Slim] IETF96

From: Natasha Rooney <[email-masked]>
Date: Tue, 19 Jul 2016 09:54:20 +0000

Hi all!

Thank-you for attending the SLIM meeting at IETF96! We have some minutes and some actions for all. If you have comments or questions on either please send them to the list. Minutes can be found at [1].

Actions for all:

  *   All - Contact mail providers to implement Multiple Language Content type
  *   Nik - adding items to Security Considerations section (then we’ll consider moving to WGLC at the end of IETF96)
  *   Natasha - clean up Use Cases draft. Leave as informational.
  *   Chairs - add items to WGLC, send details to the list.

Thanks to Lucas Jenß for being our jabber scribe and Brian Rosen for being our scribe. Thanks to the ADs for attending, and Nik, Randall and Gunnar for presenting!

Natasha

[1] https://www.ietf.org/proceedings/96/minutes/minutes-96-slim

Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 19 Jul 2016 07:35:31 -0700

To address the two action items in the real-time draft from today's 
discussion, I propose to make the following two changes:

Replace all of Section 5 with:

    RFC 4566 [RFC4566] specifies an attribute 'lang' which appears
    similar to what is needed here, but in considering its use the group
    felt its semantics were ambiguous, noted that there was not much
    evidence of its use (and thus less likelihood of conflict or
    confusion in defining new attributes), and that there was value in
    being able to specify language per direction (sending and receiving).
    This document therefore defines two new attributes.

This deletes all interpretation of the existing attribute (while 
retaining mention that interpretation is needed) and mentions the 
value in being able to specify language per direction.

In Section 6.2, change "the languages the offerer wishes to" to 
"...is willing to".

If you feel these changes are not correct, please say so now.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
There are three possibilities: Pioneer's solar panel has turned
away from the sun; there's a large meteor blocking transmission;
or someone loaded Star Trek 3.2 into our video processor.

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 19 Jul 2016 22:52:32 +0200

Randall,

> Replace all of Section 5 with:
I still think it is not our task to criticize RFC 4566 when we do not 
need. I proposed to just motivate our decision on the fact that the lang 
attribute does not have sufficient detail. We have agreed to describe 
languages per direction, and that is not supported by 'lang'

So, here is my proposed rewording:

    RFC 4566 [RFC4566] specifies an attribute 'lang' which appears
    similar to what is needed here. We need however a more detailed 
specification than the 'lang' attribute provides.    We need a way to 
negotiate which language is used in each stream and direction in the 
session. This document therefore defines two new attributes.
(Your proposal was
> value in being able to specify language per direction.
)
>
> In Section 6.2, change "the languages the offerer wishes to" to "...is 
> willing to".
You mentioned "is capable to" during the meeting. I think that is 
better. We need to avoid to give the impression that the user in the 
normal case intends to use more than one of the indicated languages. "is 
willing to" is better than "wishes" but I still think that "is capable 
of" is even more free of implication that the desire is to use more than 
one.

There are two more occurrences of "wishes" in section 6.2. Please look 
at the change proposal file I just sent to the list and make your 
proposals from it ( I know my proposals are not perfect either).

Earlier ( in April) you also proposed to delete the phrase "to indicate the language used when sending and receiving media" at the end of the first paragraph in 6.2. I still support that proposal,
  because the full reasoning of the purpose and usage of the attributes follow.

> If you feel these changes are not correct, please say so now.
Regards
Gunnar

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

---

From: Randall Gellens <[email-masked]>
Date: Tue, 19 Jul 2016 14:24:18 -0700

At 10:52 PM +0200 7/19/16, Gunnar Hellström wrote:

>>  To address the two action items in the 
>> real-time draft from today's discussion, I 
>> propose to make the following two changes:
>>
>  I still think it is not our task to criticize 
> RFC 4566 when we do not need. I proposed to 
> just motivate our decision on the fact that the 
> lang attribute does not have sufficient detail. 
> We have agreed to describe languages per 
> direction, and that is not supported by 'lang'

The history of that decision is that it was done 
after the agreement that the existing 'lang' 
attribute couldn't be used.  It's additional, I'm 
not sure it's sufficient.  If you object so 
strongly to the simple statement that the 
existing semantics are not clear (which is 
evidenced by the debate over what they mean), I 
can delete all justification and simply say that 
the group decided not to use it.  After all, 
anything we say as to why can be argued with, as 
you are doing here.

>  similar to what is needed here. We need however 
> a more detailed specification than the 'lang' 
> attribute provides. We need a way to negotiate 
> which language is used in each stream and 
> direction in the session. This document 
> therefore defines two new attributes.
>
>>
>>
>>
>  (Your proposal was
>
>>  This deletes all interpretation of the 
>> existing attribute (while retaining mention 
>> that interpretation is needed) and mentions 
>> the value in being able to specify language 
>> per direction.
>>
>  )
>
>>
>>  In Section 6.2, change "the languages the 
>> offerer wishes to" to "...is willing to".
>>
>  You mentioned "is capable to" during the meeting. I think that is better.

I mentioned it because it was your suggested 
phrase and I feel it is not clear nor correct 
English nor correct technically.  What I 
suggested in the meeting was saying "supports" 
which is what I think you meant by "is capable 
to", but when I made the change to the draft, I 
realized that it was incorrect.  Most clients 
will be capable of supporting virtually any 
language; obviously the client isn't going to try 
and establish sessions for every language.  It's 
going to do what it determines the user wants.  I 
think the original wording of "wishes" is best 
but I am happy to change it.

>  We need to avoid to give the impression that 
> the user in the normal case intends to use more 
> than one of the indicated languages.

No, we do not, because that gets into user 
interface issues which are out of scope.  We need 
to establish at the protocol level which 
languages are established.

>   "is willing to" is better than "wishes" but I 
> still think that "is capable of" is even more 
> free of implication that the desire is to use 
> more than one.
>
>  There are two more occurrences of "wishes" in 
> section 6.2. Please look at the change proposal 
> file I just sent to the list and make your 
>  Earlier ( in April) you also proposed to delete 
> the phrase "to indicate the language used when 
> sending
>  and receiving media" at the end of the first 
> paragraph in 6.2. I still support that proposal,

That change was made but missed getting in to 
-01.  It is in -02.  I didn't include it in the 
email because it was stylistic and not germane to 
the action item, so I felt it would be confusing 
to include.

Here is the full paragraph as it is now:

    In an offer, 'humintlang-send' indicates the language(s) the offerer
    is willing to use when sending using the media, and 'humintlang-recv'
    indicates the language(s) the offerer is willing to use when
    receiving using the media.  In both cases the values constitute a
    list of languages in preference order (first is most preferred).  In
    cases where the user wishes to use a media in one direction only
    (such as a speech-impaired user who wishes to send using text and
    receive using audio), one of the two MAY be unset.  In cases where a
    media is not primarily intended for language (for example, a video or
    audio stream intended for background only) both SHOULD be unset.  In
    other cases, both SHOULD have the same values in the same order.  The
    two SHOULD NOT be set to languages which are difficult to match
    together (e.g., specifying a desire to send audio in Hungarian and
    receive audio in Portuguese will make it difficult to successfully
    complete the call).

>  <mailto:[email-masked]>[email-masked]
>  +46 708 204 288
>
>  _______________________________________________
>  SLIM mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/slim

-------------- Randomly selected tag: ---------------
He had occasional flashes of silence that made his conversation
perfectly delightful.                            --Sydney Smith

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 20 Jul 2016 00:30:38 +0200

Den 2016-07-19 kl. 23:24, skrev Randall Gellens:

>>  I still think it is not our task to criticize RFC 4566 when we do 
>> not need. I proposed to just motivate our decision on the fact that 
>> the lang attribute does not have sufficient detail. We have agreed to 
>> describe languages per direction, and that is not supported by 'lang'
>
> The history of that decision is that it was done after the agreement 
> that the existing 'lang' attribute couldn't be used. It's additional, 
> I'm not sure it's sufficient.  If you object so strongly to the simple 
> statement that the existing semantics are not clear (which is 
> evidenced by the debate over what they mean), I can delete all 
> justification and simply say that the group decided not to use it.  
> After all, anything we say as to why can be argued with, as you are 
> doing here.
A motivation is needed, and the clear one is the direction. Please use that.
>> better.
> I mentioned it because it was your suggested phrase and I feel it is 
> not clear nor correct English nor correct technically.  What I 
> suggested in the meeting was saying "supports" which is what I think 
> you meant by "is capable to", but when I made the change to the draft, 
> I realized that it was incorrect.  Most clients will be capable of 
> supporting virtually any language; obviously the client isn't going to 
> try and establish sessions for every language. It's going to do what 
> it determines the user wants.  I think the original wording of 
> "wishes" is best but I am happy to change it.
>
>>  We need to avoid to give the impression that the user in the normal 
>> case intends to use more than one of the indicated languages.
>
> No, we do not, because that gets into user interface issues which are 
> out of scope.  We need to establish at the protocol level which 
>>   "is willing to" is better than "wishes" but I still think that "is 
>> capable of" is even more free of implication that the desire is to 
>> use more than one.
>>
>>  There are two more occurrences of "wishes" in section 6.2. Please 
>> look at the change proposal file I just sent to the list and make 
>> your proposals from it ( I know my proposals are not perfect either).
>>
>>  Earlier ( in April) you also proposed to delete the phrase "to 
>> indicate the language used when sending
>>  and receiving media" at the end of the first paragraph in 6.2. I 
>> still support that proposal,
> That change was made but missed getting in to -01.  It is in -02. I 
> didn't include it in the email because it was stylistic and not 
> germane to the action item, so I felt it would be confusing to include.
>
OK, I can accept "is willing". So, this text is close to good.

However, there is another small item, I remember I bounced at the first 
times I read this. It is this phrase:
" In cases where the user wishes to use a media in one direction only
    (such as a speech-impaired user who wishes to send using text and
    receive using audio), one of the two MAY be unset."

I was thinking of "the two" as text and speech attributes and wondered 
why you did not want to set both.
Eventually I realized that you thought about the two directions of each 
media. So, I suggest to clarify like this:

In cases where the user wishes to use a media in one direction only
    (such as a speech-impaired user who wishes to send using text and
    receive using audio), one of the two MAY be unsetfor that media.

/Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Wed, 20 Jul 2016 02:04:56 -0700

At 12:30 AM +0200 7/20/16, Gunnar Hellström wrote:

>>> just motivate our decision on the fact that 
>>> the lang attribute does not have sufficient 
>>> detail. We have agreed to describe languages 
>>> per direction, and that is not supported by 
>>> 'lang'
>>>
>>
>>  The history of that decision is that it was 
>> done after the agreement that the existing 
>> 'lang' attribute couldn't be used. It's 
>> additional, I'm not sure it's sufficient. If 
>> you object so strongly to the simple statement 
>> that the existing semantics are not clear 
>> (which is evidenced by the debate over what 
>> they mean), I can delete all justification and 
>> simply say that the group decided not to use 
>> it. After all, anything we say as to why can 
>> be argued with, as you are doing here.
>>

As I said, directionality was considered only 
after it was agreed that the existing attribute 
wasn't suitable.  The draft need only reflect 
group consensus.  The level of detail and 
justification is not mandated.  Personally, I 
prefer more background information, but I am OK 
saying very little to avoid endless debate over 
words.

>>>  similar to what is needed here. We need 
>>> however a more detailed specification than 
>>> the 'lang' attribute provides. We need a way 
>>> to negotiate which language is used in each 
>>> stream and direction in the session. This 
>>> document therefore defines two new attributes.
>>>
>>>>
>>>>
>>>>
>>>  (Your proposal was
>>>
>> to", but when I made the change to the draft, 
>> I realized that it was incorrect. Most clients 
>> language; obviously the client isn't going to 
>> try and establish sessions for every language. 
>> It's going to do what it determines the user 
>> wants. I think the original wording of 
>>> the user in the normal case intends to use 
>>> more than one of the indicated languages.
>>>
>>
>> interface issues which are out of scope. We 
>> need to establish at the protocol level which 
>>> section 6.2. Please look at the change 
>>> proposal file I just sent to the list and 
>>> make your proposals from it ( I know my 
>>> proposals are not perfect either).
>>>
>>>  Earlier ( in April) you also proposed to 
>>> delete the phrase "to indicate the language 
>>> used when sending
>> email because it was stylistic and not germane 
>> to the action item, so I felt it would be 
>> confusing to include.
>>

Happy to hear it.

>
>  However, there is another small item, I 
> remember I bounced at the first times I read 
> this. It is this phrase:
>  I was thinking of "the two" as text and speech 
> attributes and wondered why you did not want to 
> set both.
>  Eventually I realized that you thought about 
> the two directions of each media. So, I suggest 
> to clarify like this:
>
>  receive using audio), one of the two MAY be unset for that media.

I have reworded the text to be more clear.  Here is the revised sentence:

    In cases where a
    media is intended for use in one direction only (such as a speech-
    impaired user sending using text and receiving using audio), either
    humintlang-send or humintlang-recv MAY be unset.

-------------- Randomly selected tag: ---------------
2 + 2 = 5 for extremely large values of 2.

---

From: Brian Rosen <[email-masked]>
Date: Wed, 20 Jul 2016 11:10:48 +0200

I find “unset” to be confusing.

Could we agree on “either of humintlang-send or humintlang-recv MAY be specified.”

Brian
> On Jul 20, 2016, at 11:04 AM, Randall Gellens <[email-masked]> wrote:
> 
>>>>> To address the two action items in the real-time draft from today's discussion, I propose to make the following two changes:
>>>>> 
>>>> I still think it is not our task to criticize RFC 4566 when we do not need. I proposed to just motivate our decision on the fact that the lang attribute does not have sufficient detail. We have agreed to describe languages per direction, and that is not supported by 'lang'
>>>> 
>>> 
>>> The history of that decision is that it was done after the agreement that the existing 'lang' attribute couldn't be used. It's additional, I'm not sure it's sufficient. If you object so strongly to the simple statement that the existing semantics are not clear (which is evidenced by the debate over what they mean), I can delete all justification and simply say that the group decided not to use it. After all, anything we say as to why can be argued with, as you are doing here.
>>> 
> As I said, directionality was considered only after it was agreed that the existing attribute wasn't suitable.  The draft need only reflect group consensus. The level of detail and justification is not mandated.  Personally, I prefer more background information, but I am OK saying very little to avoid endless debate over words.
> 
>> 
>>> 
>>>> 
>>>> similar to what is needed here. We need however a more detailed specification than the 'lang' attribute provides. We need a way to negotiate which language is used in each stream and direction in the session. This document therefore defines two new attributes.
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> (Your proposal was
>>>> 
>>>>> This deletes all interpretation of the existing attribute (while retaining mention that interpretation is needed) and mentions the value in being able to specify language per direction.
>>>>> 
>>>> )
>>>> 
>>>>> 
>>>>> In Section 6.2, change "the languages the offerer wishes to" to "...is willing to".
>>>>> 
>>> I mentioned it because it was your suggested phrase and I feel it is not clear nor correct English nor correct technically. What I suggested in the meeting was saying "supports" which is what I think you meant by "is capable to", but when I made the change to the draft, I realized that it was incorrect. Most clients will be capable of supporting virtually any language; obviously the client isn't going to try and establish sessions for every language. It's going to do what it determines the user wants. I think the original wording of "wishes" is best but I am happy to change it.
>>> 
>>>> We need to avoid to give the impression that the user in the normal case intends to use more than one of the indicated languages.
>>>> 
>>> 
>>> No, we do not, because that gets into user interface issues which are out of scope. We need to establish at the protocol level which languages are established.
>>> 
>>>> "is willing to" is better than "wishes" but I still think that "is capable of" is even more free of implication that the desire is to use more than one.
>>>> 
>>>> There are two more occurrences of "wishes" in section 6.2. Please look at the change proposal file I just sent to the list and make your proposals from it ( I know my proposals are not perfect either).
>>>> 
>>>> Earlier ( in April) you also proposed to delete the phrase "to indicate the language used when sending
>>>> and receiving media" at the end of the first paragraph in 6.2. I still support that proposal,
>>> That change was made but missed getting in to -01. It is in -02. I didn't include it in the email because it was stylistic and not germane to the action item, so I felt it would be confusing to include.
>>> 
>> However, there is another small item, I remember I bounced at the first times I read this. It is this phrase:
>> I was thinking of "the two" as text and speech attributes and wondered why you did not want to set both.
>> Eventually I realized that you thought about the two directions of each media. So, I suggest to clarify like this:
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 20 Jul 2016 11:22:58 +0200

Randall,

Den 2016-07-20 kl. 11:04, skrev Randall Gellens:
>>
>>  However, there is another small item, I remember I bounced at the 
>> first times I read this. It is this phrase:
>>  I was thinking of "the two" as text and speech attributes and 
>> wondered why you did not want to set both.
>>  Eventually I realized that you thought about the two directions of 
>> each media. So, I suggest to clarify like this:
>>
Sorry, but that misses the point. Why can you not take my proposal?
The point is that the statement is written as implicitly valid per 
media, while the reader ( at least me) may be thinking per use case. 
Therefore, guidance to think per media would be good, in order to not 
cause confusion or wondering what is meant.

So, therefore I suggest:

In cases where a
    media is intended for use in one direction only (such as a speech-
    impaired user sending using text and receiving using audio), either
    humintlang-send or humintlang-recv MAY be unset for each media.

/Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 20 Jul 2016 11:24:59 +0200

> Could we agree on “either of humintlang-send or humintlang-recv MAY be 
I would also prefer that for all occasions of "unset".

/Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Wed, 20 Jul 2016 02:33:06 -0700

At 11:10 AM +0200 7/20/16, Brian Rosen wrote:

>  I find "unset" to be confusing.

How about "omitted"?

    In cases where a
    media is intended for use in one direction only (such as a speech-
    impaired user sending using text and receiving using audio), either
    humintlang-send or humintlang-recv MAY be omitted.  In cases where a
    media is not primarily intended for language (for example, a video or
    audio stream intended for background only) both SHOULD be omitted.
>
>  Could we agree on "either of humintlang-send or 
> humintlang-recv MAY be specified."
>
>  Brian
>
>>  On Jul 20, 2016, at 11:04 AM, Randall Gellens 
>> <<mailto:[email-masked]>[email-masked]> 
>> wrote:
>>
>>>>>  I still think it is not our task to 
>>>>> criticize RFC 4566 when we do not need. I 
>>>>> proposed to just motivate our decision on 
>>>>> the fact that the lang attribute does not 
>>>>> have sufficient detail. We have agreed to 
>>>> you object so strongly to the simple 
>>>> statement that the existing semantics are 
>>>> not clear (which is evidenced by the debate 
>>>> over what they mean), I can delete all 
>>>> justification and simply say that the group 
>>>> decided not to use it. After all, anything 
>>>> we say as to why can be argued with, as you 
>>>> are doing here.
>>>>
>> after it was agreed that the existing 
>> attribute wasn't suitable.  The draft need 
>> only reflect group consensus. The level of 
>> detail and justification is not mandated. 
>>  Personally, I prefer more background 
>> information, but I am OK saying very little to 
>> avoid endless debate over words.
>>
>>>
>>>>
>>>>>
>>>>> the 'lang' attribute provides. We need a 
>>>>> way to negotiate which language is used in 
>>>>> each stream and direction in the session. 
>>>>>> existing attribute (while retaining 
>>>>>> mention that interpretation is needed) and 
>>>>>> mentions the value in being able to 
>>>>>> specify language per direction.
>>>>>>
>>>>>  )
>>>>>
>>>>>>
>>>> phrase and I feel it is not clear nor 
>>>> correct English nor correct technically. 
>>>> What I suggested in the meeting was saying 
>>>> "supports" which is what I think you meant 
>>>> by "is capable to", but when I made the 
>>>> change to the draft, I realized that it was 
>>>> incorrect. Most clients will be capable of 
>>>> supporting virtually any language; obviously 
>>>> the client isn't going to try and establish 
>>>> sessions for every language. It's going to 
>>>> do what it determines the user wants. I 
>>>> think the original wording of "wishes" is 
>>>> best but I am happy to change it.
>>>>
>>>>>  We need to avoid to give the impression 
>>>>> that the user in the normal case intends to 
>>>>> use more than one of the indicated 
>>>>> languages.
>>>>>
>>>>
>>>> need to establish at the protocol level 
>>>> which languages are established.
>>>>
>>>>>  "is willing to" is better than "wishes" but 
>>>>> I still think that "is capable of" is even 
>>>>> more free of implication that the desire is 
>>>>> to use more than one.
>>>>>
>>>>>  There are two more occurrences of "wishes" 
>>>>> in section 6.2. Please look at the change 
>>>>>  and receiving media" at the end of the 
>>>>> first paragraph in 6.2. I still support 
>>>>> that proposal,
>>>>  That change was made but missed getting in 
>>>> to -01. It is in -02. I didn't include it in 
>>>> the email because it was stylistic and not 
>>>  I was thinking of "the two" as text and 
>>> speech attributes and wondered why you did 
>>> not want to set both.
>>> the two directions of each media. So, I 
>>> suggest to clarify like this:
>>>
>>  <mailto:[email-masked]>[email-masked]
>> 
>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim

-------------- Randomly selected tag: ---------------
There is so much to be said in favor of modern journalism.
By giving us the opinions of the uneducated, it keeps us in touch
with the ignorance of the community.                --Oscar Wilde

---

From: Brian Rosen <[email-masked]>
Date: Wed, 20 Jul 2016 11:34:32 +0200

works for me
> On Jul 20, 2016, at 11:33 AM, Randall Gellens <[email-masked]> wrote:
>

---

From: Randall Gellens <[email-masked]>
Date: Wed, 20 Jul 2016 02:38:36 -0700

>  Sorry, but that misses the point. Why can you not take my proposal?

I found your proposal to be unclear and 
unhelpful, since the context is a per-media 
description, so I do not see where a reader would 
think per use case.  I accept that you found the 
original wording unclear, so I reworded it to be 
more clear.  What is wrong with the new wording? 
What is it that you find unclear?  If I better 
understood where you are confused, I can suggest 
other wording.  I am going to guess that is is 
the phrase "in cases" that is causing your 
confusion.  I think I can simply delete this.

So, here is the revised paragraph:

    In an offer, 'humintlang-send' indicates the language(s) the offerer
    is willing to use when sending using the media, and 'humintlang-recv'
    indicates the language(s) the offerer is willing to use when
    receiving using the media.  The values constitute a list of languages
    in preference order (first is most preferred).  When a media is
    intended for use in one direction only (such as a speech-impaired
    user sending using text and receiving using audio), either
    humintlang-send or humintlang-recv MAY be omitted.  When a media is
    not primarily intended for language (for example, a video or audio
    stream intended for background only) both SHOULD be omitted.
    Otherwise, both SHOULD have the same values in the same order.  The
    two SHOULD NOT be set to languages which are difficult to match
    together (e.g., specifying a desire to send audio in Hungarian and
    receive audio in Portuguese will make it difficult to successfully
    complete the call).

>  The point is that the statement is written as 
> implicitly valid per media, while the reader ( 
> at least me) may be thinking per use case. 
> Therefore, guidance to think per media would be 
> good, in order to not cause confusion or 
> wondering what is meant.
>
>  So, therefore I suggest:
>
>  In cases where a

-------------- Randomly selected tag: ---------------
Levellers wish to level down as far as themselves; but they cannot
bear levelling up to themselves.                --Dr. Samuel Johnson

---

From: Randall Gellens <[email-masked]>
Date: Wed, 20 Jul 2016 02:39:31 -0700

My reply to Brian a few minutes ago deleted all uses of the word "unset."

At 11:24 AM +0200 7/20/16, Gunnar Hellström wrote:

>>  Could we agree on "either of humintlang-send 
>> or humintlang-recv MAY be specified."
>>

-------------- Randomly selected tag: ---------------
C++ leads to bad design choices and is only used by substandard programmers.
    --Linus Torvalds, September 6, 2007

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 20 Jul 2016 14:01:35 +0200

works for me

/Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 20 Jul 2016 14:05:08 +0200

Yes, that works.

Gunnar

Den 2016-07-20 kl. 11:38, skrev Randall Gellens:
> I found your proposal to be unclear and unhelpful, since the context 
> is a per-media description, so I do not see where a reader would think 
> per use case.  I accept that you found the original wording unclear, 
> so I reworded it to be more clear.  What is wrong with the new 
> wording? What is it that you find unclear?  If I better understood 
> where you are confused, I can suggest other wording.  I am going to 
> guess that is is the phrase "in cases" that is causing your