Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt

[Randall Gellens <[e-mail]>]

At 2:37 PM +0100 2/27/17, Gunnar Hellström wrote:

>  Den 2017-02-27 kl. 02:01, skrev Randall Gellens:
>>  At 8:38 AM +0100 2/26/17, Gunnar Hellström wrote:
>>
>>>   Randall,
>>>
>>>   One more clarification for issue 12 - the 
>>> asterisk placement as a preference hint:
>>>
>>>   You say:
>>>
>>>   " it seems better for the answerer to 
>>> include all media and languages from the 
>>> offer that it can support. "
>>>
>>>   You are right. I misread this paragraph in section 5.2:
>>>   " In an answer, 'humintlang-send' is the language the answerer will
>>>   send (which in most cases is one of the languages in the offer's
>>>   'humintlang-recv'), and 'humintlang-recv' is the language the
>>>   answerer expects to receive (which in most cases is one of the
>>>   languages in the offer's 'humintlang-send')."
>>>
>>>   That gave me the impression that I need to 
>>> answer with only one language per direction 
>>> in the whole SDP.
>>
>>  It's per media.
>>
>>>   But in the first paragraph of 5.2, it is said: "to negotiate
>>>   which human language is used in each interactive media stream. "
>>>
>>>   So, we are allowed to include more than one 
>>> language per direction in the SDP, but the 
>>> users are not expected to use more than one 
>>> language per direction, at least initially in 
>>> the call.
>>
>>  There's nothing in the protocol that says 
>> anything about people using more than one 
>> media in each direction.
>>
>>>   (that makes the wording "will send" and 
>>> "expects to receive" in the cited paragraph a 
>>> bit misleading, because as you point out, 
>>> some of them might never be used. "is 
>>> prepared to send" and "can accept to receive" 
>>> might better correspond to what it means. 
>>> Ending the sentence with "per media steram" 
>>> might also help to remind the reader about 
>>> the semantics. I leave to you to change these 
>>> if you want.)
>>
>>  OK, I'm happy to add the additional clarification.  The paragraph now reads:
>>
>>     In an answer, 'hlang-send' is the language the answerer will send
>>     when using the media (which in most cases is one of the languages in
>>     the offer's 'hlang-recv'), and 'hlang-recv' is the language the
>>     answerer expects to receive in the media (which in most cases is one
>>     of the languages in the offer's 'hlang-send').
>
>  Yes, that might be acceptable if "will send 
> when using the media" can be read as being 
> conditional: "will send if use of the media for 
> language purposes is selected",
>  but not if it is read as a definite usage "will 
> send for the periods of time that this media 
> will definitively be used for language 
> communication."  With the latter interpretation 
> we have not improved our logic over the lang 
> attribute that could be interpreted as it 
> required use of all declared languages in the 
> session.

I think "when using the media" is clear.

>
>  I still think it is safer to say "is prepared 
> to send" instead of "will send".
>  While for the other direction, I think the 
> "expects to receive" is vague enough to mean 
> that another media might be used.
>
>  Sorry for continuing to watch out for logic gaps here.
>
>  Gunnar
>>
>>
>>
>>>   Den 2017-02-26 kl. 07:46, skrev Gunnar Hellström:
>>>
>>>>   Den 2017-02-25 kl. 20:58, skrev Randall Gellens:
>>>>
>>>>>   Hi Gunnar,
>>>>>
>>>>>   At 11:04 AM +0100 2/25/17, Gunnar Hellström wrote:
>>>>>
>>>>>>   Fine, I find that we have only issues 5, 6 and 12 still to discuss.
>>>>>>
>>>>>>   You did not answer issue 6, use of 
>>>>>> asymmetrical language rather than 
>>>>>> unidirectional media. I assume you 
>>>>>> accepted it.
>>>>>>
>>>>>
>>>>>   Yes, I thought I had indicated that, sorry if I didn't.
>>>>>
>>>>   Good.
>>>>
>>>>>
>>>>>>
>>>>>>   On 5, the request to reinsert wording 
>>>>>> about seeing the speaker in video, it is 
>>>>>> still a huge difference in specifying a 
>>>>>> preference to see the speaker for language 
>>>>>> perception reasons, versus only specifying 
>>>>>> that I want a video stream for 
>>>>>> supplementary purposes. With the current 
>>>>>> wording in version -07, section 5.3 says 
>>>>>> that that combination is undefined. 
>>>>>> Nothing in the LC discussion indicated 
>>>>>> that it should be undefined. Why did you 
>>>>>> suddenly want to delete it? It is useful. 
>>>>>> Please reinsert with the wording changes I 
>>>>>> propose.
>>>>>>
>>>>>
>>>>>   The email discussion led me to believe 
>>>>> that the text was controversial. We need to 
>>>>> get the draft finished, so it's better to 
>>>>> delete controversial text than to spend 
>>>>> months fighting about it.
>>>>>
>>>>   The comments were first about the 
>>>> uncertainty about how the "silly states" 
>>>> were to be interpreted.
>>>>   We described them all but decided to only 
>>>> keep the view of the speaker because it is a 
>>>> real and useful case.
>>>>   The idea to differentiate spoken and 
>>>> written cases by script tags caused 
>>>> discussions and was dropped. The remaining 
>>>> real case with the view of the speaker was 
>>>> mentioned twice in the draft, so it was 
>>>> recommended that one of them should be 
>>>> deleted, but not both.
>>>>
>>>>>
>>>>>>
>>>>>>   On 12, the meaning of the placement of the asterisk, you ask:
>>>>>>   "Making the asterisk a purely-advisory 
>>>>>> hint as to the least-preferred 
>>>>>> media/language combination seems harmless 
>>>>>> enough, as it would not be required to 
>>>>>> support it; however, I'm not sure it 
>>>>>> provides any benefit: if an offer contains 
>>>>>> some set of media with language, and the 
>>>>>> answerer can support all of them, should 
>>>>>> the answerer only include in its answer 
>>>>>> those without an asterisk? It seems 
>>>>>> simpler for the answerer to include 
>>>>>> everything in the offer that it can 
>>>>>> support."
>>>>>>
>>>>>>   The answering party should aim at 
>>>>>> answering with one of the languages that 
>>>>>> is without the asterisk in the offer. Only 
>>>>>> if the answering party does not have 
>>>>>> capability in a language without an 
>>>>>> asterisk, one with asterisk should be 
>>>>>> selected. Thereby you get the best 
>>>>>> opportunity to start the call in a 
>>>>>> language combination that satisfies both 
>>>>>> users.
>>>>>>
>>>>>>   Example: A hard-of-hearing user can just 
>>>>>> barely conduct spoken calls with persons 
>>>>>> she knows. From others it is much more 
>>>>>> reliable to get text. She calls and 
>>>>>> declares:
>>>>>>
>>>>>>   m=audio
>>>>>>   a=huml-send:en
>>>>>>   a=huml-recv:en*
>>>>>>   m=text
>>>>>>   a=huml-recv:en
>>>>>>
>>>>>>   The answering party with text 
>>>>>> capabilities sees that matching text for 
>>>>>> sending is higher preferred than talking, 
>>>>>> and thus responds:
>>>>>>
>>>>>>   m=audio
>>>>>>   a=huml-recv:en
>>>>>>   m=text
>>>>>>   a=huml-send:en
>>>>>>
>>>>>>   The answering party sends the initial 
>>>>>> greeting in text and the call continues 
>>>>>> smoothly in well managed 
>>>>>> langauage/modality combinations.
>>>>>>
>>>>>>   Another called party may not have text 
>>>>>> capabilities, and may therefore select the 
>>>>>> less favoured alternative with using 
>>>>>> speech both ways, answering:
>>>>>>
>>>>>>   m=audio
>>>>>>   a=huml-recv:en
>>>>>>   a=huml-send:en
>>>>>>   m=text 0
>>>>>>
>>>>>>   The answering party starts taking and the 
>>>>>> parties try as well as possible to manage 
>>>>>> the call in this less preferred 
>>>>>> combination that may be less reliable.
>>>>>>
>>>>>>   If the placement of the asterisk had no 
>>>>>> special meaning as it is in version -07, 
>>>>>> it is a high risk that the answering party 
>>>>>> in the first example would select to 
>>>>>> answer with spoken language that would be 
>>>>>> unreliably received. Time and effort would 
>>>>>> be spent by speech to make the answering 
>>>>>> party switch to sending text instead of 
>>>>>> talking in order to arrange for a more 
>>>>>> reliable call situation.
>>>>>>
>>>>>>   If instead the caller only indicated the most favoured combinations,
>>>>>>
>>>>>>   m=audio
>>>>>>   a=huml-send:en
>>>>>>   m=text
>>>>>>   a=huml-recv:en
>>>>>>
>>>>>>   Then the answering parties without text 
>>>>>> capability would not dare to try to 
>>>>>> answer, and a reasonably successful call 
>>>>>> would be missed.
>>>>>>
>>>>>>   Many other similar realistic examples can 
>>>>>> be created, where placement of the 
>>>>>> asterisk(s) would be a sufficient 
>>>>>> indication of lower preference for 
>>>>>> language match among alternatives that 
>>>>>> would make call establishment successful 
>>>>>> and smooth in many more cases than without 
>>>>>> this indication opportunity.
>>>>>>
>>>>>>   Do you want more examples?
>>>>>>
>>>>>>   Please accept proposal 12.
>>>>>>
>>>>>
>>>>>   This convinces me that we cannot accept 
>>>>> the proposed text, as it would introduce 
>>>>> complexity that the WG explicitly decided 
>>>>> to not pursue in this draft. In the 
>>>>> examples you provided, it seems better for 
>>>>> the answerer to include all media and 
>>>>> languages from the offer that it can 
>>>>> support. This is much simpler, has only 
>>>>> trivial drawbacks (extra media negotiated 
>>>>> that might not be used), and is what the WG 
>>>>> agreed to.
>>>>>
>>>>   Yes, you could let the answer SDP contain 
>>>> one common language per media and direction, 
>>>> but the answering human need guidance on 
>>>> which language is best suited to start the 
>>>> conversation. Therefore the placement of the 
>>>> asterisk is used to hint the answering party 
>>>> how to start the call.
>>>>
>>>>   The first example above can be modified to:
>>>>
>>>>   Example: A hard-of-hearing user can just 
>>>> barely conduct spoken calls with persons she 
>>>> knows. From others it is much more reliable 
>>>> to get text. She calls and declares:
>>>>
>>>>   m=audio
>>>>   a=huml-send:en
>>>>   a=huml-recv:en*
>>>>   m=text
>>>>   a=huml-recv:en
>>>>
>>>>   The answering party with capabilities for 
>>>> both written and spoken English sees that 
>>>> matching text for sending is higher 
>>>> preferred than talking and sends the answer 
>>>> indicating the capabilities:
>>>>
>>>>   m=audio
>>>>   a=huml-recv:en
>>>>   a=huml-send:en
>>>>   m=text
>>>>   a=huml-send:en
>>>>
>>>>   The answering party makes use of the hint 
>>>> that the caller prefers to receive written 
>>>> text and therefore sends the initial 
>>>> greeting in text and the call continues 
>>>> smoothly in well managed langauage/modality 
>>>> combinations.
>>>>
>>>>   ----------
>>>>   There is no complexity left in this 
>>>> solution, it helps to motivate why we have 
>>>> the asterisk on media level, and it helps to 
>>>> successful call initiations, so I think it 
>>>> should be acceptable.
>>>>
>>>>   Gunnar
>>>>
>>>>>
>>>>>   --Randy
>>>>>
>>>>>>   Den 2017-02-25 kl. 01:32, skrev Randall Gellens:
>>>>>>
>>>>>>>   At 5:35 PM +0100 2/24/17, Gunnar Hellström wrote:
>>>>>>>
>>>>>>>>   Den 2017-02-23 kl. 05:15, skrev Randall Gellens:
>>>>>>>>
>>>>>>>>>   Version -07 addresses all comments 
>>>>>>>>> except for the unresolved issue of 
>>>>>>>>> renaming the two attributes which is 
>>>>>>>>> currently being discussed on the list, 
>>>>>>>>> and adding a new attribute for 
>>>>>>>>> bidirectionality.
>>>>>>>>>
>>>>>>>>>   Per Dale's suggestion, the draft adds 
>>>>>>>>> advice that if a call is rejected due 
>>>>>>>>> to no languages in common, SIP response 
>>>>>>>>> code 488 (Not Acceptable Here) or 606 
>>>>>>>>> (Not Acceptable) be used, along with a 
>>>>>>>>> Warning header field indicating the 
>>>>>>>>> supported languages. The draft 
>>>>>>>>> registers a new entry in the warn-code 
>>>>>>>>> sub-registry of SIP parameters for this 
>>>>>>>>> purpose. The draft also has an expanded 
>>>>>>>>> set of examples.
>>>>>>>>>
>>>>>>>>   Good progress. Good to see the enriched examples chapter 5.5.
>>>>>>>>   I have a few comments on version -07:
>>>>>>>>
>>>>>>>>   1. Section 4. second line
>>>>>>>>   ------------old text----------------------
>>>>>>>>   but is not sufficiently sufficiently
>>>>>>>>   ------------new text--------------------------
>>>>>>>>   but is not sufficiently
>>>>>>>>   ----------end of change 1-----------------
>>>>>>>>   Motivation: New typo in version -07
>>>>>>>>
>>>>>>>
>>>>>>>   Thanks.
>>>>>>>
>>>>>>>>
>>>>>>>>   2. Section 5.2, first line
>>>>>>>>   ----------------old text-----------------
>>>>>>>>   This document defines two new media-level ..
>>>>>>>>   ----------------new text----------------------
>>>>>>>>   This document defines two media-level ...
>>>>>>>>   ----------------end of change 2----------------
>>>>>>>>   Motivation: It was commented that when 
>>>>>>>> the draft is published, this is not new 
>>>>>>>> anymore.
>>>>>>>>   There are three more occasions of "new" 
>>>>>>>> in the document that may be modified as 
>>>>>>>> well.
>>>>>>>>
>>>>>>>
>>>>>>>   OK.
>>>>>>>
>>>>>>>>
>>>>>>>>   3. 5.2 second paragraph
>>>>>>>>   -------------------old text--------------------------------
>>>>>>>>   In an offer, the 'humintlang-send' values indicates the language(s)
>>>>>>>>   the offerer is willing to use when sending using the media, and the
>>>>>>>>   'humintlang-recv' values indicates the language(s) the offerer is
>>>>>>>>   willing to use when receiving using the media.
>>>>>>>>   -----------------new text---------------------------------
>>>>>>>>   In an offer, the 'humintlang-send' values indicate the language(s)
>>>>>>>>   the offerer is willing to select from for use when sending using the
>>>>>>>>   media, and the 'humintlang-recv' values indicate the language(s) the
>>>>>>>>   offerer is willing to receive one of in the media stream.
>>>>>>>>   ----------------end of change----------------------------------
>>>>>>>>   Motivation 1:) change from "indicates" 
>>>>>>>> to "indicate" in two places to match the 
>>>>>>>> new use of plural "values".
>>>>>>>>   Motivation 2:) Be sure to indicate that 
>>>>>>>> we only intend to negotiate one language 
>>>>>>>> per media and direction, so that we do 
>>>>>>>> not end up as unspecified regarding 
>>>>>>>> number of matches required as the sdp 
>>>>>>>> "lang" attribute is.
>>>>>>>>
>>>>>>>
>>>>>>>   Reworded.
>>>>>>>
>>>>>>>>
>>>>>>>>   4. 5.2 Second paragraph
>>>>>>>>   -----------------old text-----------------------
>>>>>>>>   When a media is intended
>>>>>>>>   for use in one direction only
>>>>>>>>   ----------------new text---------------------
>>>>>>>>   When a media is intended
>>>>>>>>   for use for language communication in one direction only
>>>>>>>>   ----------------end of change---------------------------
>>>>>>>>   Motivation: Deletion of a note in this 
>>>>>>>> sentence made it less obvious that we 
>>>>>>>> are only talking about directions of use 
>>>>>>>> of language communication, and not about 
>>>>>>>> establishing asymmetric media 
>>>>>>>> connections. Therefore add this 
>>>>>>>> clarification.
>>>>>>>>
>>>>>>>
>>>>>>>   Reworded.
>>>>>>>
>>>>>>>>
>>>>>>>>   5. 5.2 Deleted paragraph 6 before "Clients acting on behalf..."
>>>>>>>>   ----------reinsert modified paragraph----------------------------
>>>>>>>>   While signed language tags are used with a video stream to
>>>>>>>>   indicate sign language, a spoken language tag for a video stream
>>>>>>>>   indicates a request or offer to see the speaker, when that is of
>>>>>>>>   importance for language perception.
>>>>>>>>   -------------end of change-------------------------------------------
>>>>>>>>   Motivation: There was in the LC mail 
>>>>>>>> exchange a discussion about sharpening 
>>>>>>>> up the specification of use of "unusual 
>>>>>>>> combinations".
>>>>>>>>   There was no agreement to delete them 
>>>>>>>> all. The one described in this paragraph 
>>>>>>>> is the main one that has widespread use 
>>>>>>>> and needs to be clearly specified for 
>>>>>>>> use by a large number of hard-of-hearing 
>>>>>>>> and deaf users.
>>>>>>>>
>>>>>>>
>>>>>>>   The text as it is now does not prohibit 
>>>>>>> anything and explicitly mentions 
>>>>>>> negotiating supplemental video by 
>>>>>>> omitting language attributes on a video 
>>>>>>> media.
>>>>>>>
>>>>>>>>
>>>>>>>>   6. 5.2 Sixth paragraph
>>>>>>>>   --------------------current text--------------------
>>>>>>>>   (or for unidirectional streams, one of)
>>>>>>>>   ------------------new text ------------------------
>>>>>>>>   (or for asymmetrical use of languages, one of)
>>>>>>>>   -----------------end of change----------------------
>>>>>>>>   Motivation: We are not primarily 
>>>>>>>> talking about enabled transmission 
>>>>>>>> directions of the streams, but about 
>>>>>>>> language use in the streams. We do not 
>>>>>>>> want to limit the media stream 
>>>>>>>> directions just because we do not 
>>>>>>>> specify an initial language to use for 
>>>>>>>> that direction. There are other usage of 
>>>>>>>> media, and there may even be occasional 
>>>>>>>> use of language in the direction, just 
>>>>>>>> not worth mentioning as an initial and 
>>>>>>>> preferred use. The suggested change 
>>>>>>>> should make that clear.
>>>>>>>>
>>>>>>>>   7. 5.3 Next to last paragraph
>>>>>>>>   ------------------old text------------------------------
>>>>>>>>   a list of supported languages.
>>>>>>>>   -------------------new text-------------------------
>>>>>>>>   a list of supported languages, media and directions.
>>>>>>>>   -------------------end of change----------------
>>>>>>>>   Motivation: It is not sufficient to 
>>>>>>>> know which languages are supported, it 
>>>>>>>> is also essential to know in which media 
>>>>>>>> they are supported and in which 
>>>>>>>> directions. (media could be replaced 
>>>>>>>> with modality, but the media can become 
>>>>>>>> ambigous then, so use media here to be 
>>>>>>>> brief.
>>>>>>>>
>>>>>>>
>>>>>>>   I don't know that we can require this, 
>>>>>>> but I'll add SHOULD kist supported 
>>>>>>> languages and media. Demanding direction 
>>>>>>> as well might be too unwieldy.
>>>>>>>
>>>>>>>>
>>>>>>>>   8. 5.3, last line
>>>>>>>>   --------------old text----------------------------------
>>>>>>>>   Supported languages are: es, en"
>>>>>>>>   --------------new text-------------------------------
>>>>>>>>   Supported languages are: es, en 
>>>>>>>> transmission in audio; es, en reception 
>>>>>>>> in audio"
>>>>>>>>   ----------------------------------------------------------
>>>>>>>>   Motivation: Same as for 7.
>>>>>>>>
>>>>>>>
>>>>>>>   Fixed as above.
>>>>>>>
>>>>>>>>
>>>>>>>>   9. 5.4 Undefined combinations
>>>>>>>>   ----------------------------old 
>>>>>>>> text--------------------------------------
>>>>>>>>   The behavior when specifying a non-signed language tag for a video
>>>>>>>>   media stream, or a signed language tag for an audio or text media
>>>>>>>>   stream, is not defined.
>>>>>>>>   ---------------------------new 
>>>>>>>> text-----------------------------------------
>>>>>>>>   There is no way specified for 
>>>>>>>> indicating use of text based language in 
>>>>>>>> a video media stream.
>>>>>>>>   There is no meaning assigned to 
>>>>>>>> specification of sign language in an 
>>>>>>>> audio or text media stream.
>>>>>>>>   --------------------------end of 
>>>>>>>> change-------------------------------
>>>>>>>>   Motivation: Seeing the speaker in video 
>>>>>>>> is an important combination reinserted 
>>>>>>>> above in section 5.2.
>>>>>>>>   This section therefore needed rewording 
>>>>>>>> to not include that combination.
>>>>>>>>
>>>>>>>
>>>>>>>   The draft explicitly mentions video for supplemental purposes.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   10. 6.2 Last sentence
>>>>>>>>   -----------------current text---------------------
>>>>>>>>   Supported languages are: [list of supported languages]."
>>>>>>>>   -----------------new text------------------------
>>>>>>>>   Supported languages and media and 
>>>>>>>> transmission directions are:[list of 
>>>>>>>> supported languages and media and 
>>>>>>>> transmission directions.]"
>>>>>>>>   -----------------end of change--------------------------
>>>>>>>>   Motivation: Same as for 7.
>>>>>>>>
>>>>>>>
>>>>>>>   Fixed as above.
>>>>>>>
>>>>>>>>
>>>>>>>>   11. 6.1 MUX Category
>>>>>>>>   ----------old text in two locations-------------------
>>>>>>>>   MUX Category: normal
>>>>>>>>   ---------new text in same two locations--------------
>>>>>>>>   Mux Category: NORMAL
>>>>>>>>   ---------end of change-----------------
>>>>>>>>   Motivation: Follow RFC 4566bis and IANA 
>>>>>>>> habits regarding use of capitals
>>>>>>>>
>>>>>>>
>>>>>>>   Fixed.
>>>>>>>
>>>>>>>>
>>>>>>>>   12. 5.3
>>>>>>>>   -------------old text-----------------
>>>>>>>>   5.3 No Language in Common
>>>>>>>>   -------------new text----------------
>>>>>>>>   5.3 Preference parameter
>>>>>>>>   ------------end of change 1 in 5.3---------------
>>>>>>>>
>>>>>>>
>>>>>>>   The section is more than just the 
>>>>>>> asterisk, it also advises use of specific 
>>>>>>> SIP response codes if the call is failed.
>>>>>>>
>>>>>>>>
>>>>>>>>   -------------old text-in 5.3, second 
>>>>>>>> paragraph-------------------------------
>>>>>>>>   The mechanism for indicating this preference is that, in an offer, if
>>>>>>>>   the last character of any of the 'humintlang-recv' or 'humintlang-
>>>>>>>>   send' values is an asterisk, this 
>>>>>>>> indicates a request to not fail the call.
>>>>>>>>   --------------------------new text-------------------------------
>>>>>>>>   The mechanism for indicating this preference is that, in an offer, if
>>>>>>>>   the last character of any of the 'humintlang-recv' or 'humintlang-
>>>>>>>>   send' values is an asterisk, this 
>>>>>>>> indicates a request to not fail the call.
>>>>>>>>   The asterisk should be attached to attributes with languages of lower
>>>>>>>>   preference to be matched if such difference can be specified. Thereby
>>>>>>>>   the location of the asterisk can be used to support the decision on
>>>>>>>>   which languages to use in the call.
>>>>>>>>   ---------------------------end of 
>>>>>>>> change 2 in 
>>>>>>>> 5.3--------------------------------------
>>>>>>>>   Motivation: There has not yet been any 
>>>>>>>> conclusion for my proposal no 5 in the 
>>>>>>>> IETF LC comments of Feb 12.
>>>>>>>>   This is a dramatically reduced version 
>>>>>>>> that may be easier to accept at this 
>>>>>>>> stage, still covering one of the missing 
>>>>>>>> functionalities in the draft.
>>>>>>>>   The asterisk is used as a preference 
>>>>>>>> parameter in the attributes. Thereby the 
>>>>>>>> proposed title change on 5.3
>>>>>>>>   With this additional rule about where 
>>>>>>>> the asterisk(s) are placed, the 
>>>>>>>> answering parties get good clues about 
>>>>>>>> the preferences between alternatives 
>>>>>>>> presented by the offeror. The chance to 
>>>>>>>> set up calls with satisfied users 
>>>>>>>> increase dramatically compared to 
>>>>>>>> letting the answering party select by 
>>>>>>>> chance between alternatives.
>>>>>>>>
>>>>>>>
>>>>>>>   Making the asterisk a purely-advisory 
>>>>>>> hint as to the least-preferred 
>>>>>>> media/language combination seems harmless 
>>>>>>> enough, as it would not be required to 
>>>>>>> support it; however, I'm not sure it 
>>>>>>> provides any benefit: if an offer 
>>>>>>> contains some set of media with language, 
>>>>>>> and the answerer can support all of them, 
>>>>>>> should the answerer only include in its 
>>>>>>> answer those without an asterisk? It 
>>>>>>> seems simpler for the answerer to include 
>>>>>>> everything in the offer that it can 
>>>>>>> support.
>>>>>>>
>>>>>>
>>>>>>   --
>>>>>>   -----------------------------------------
>>>>>>   Gunnar Hellström
>>>>>>   Omnitor
>>>>>>   <mailto:[e-mail]>[e-mail]
>>>>>>   [phone]
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>   --
>>>   -----------------------------------------
>>>   Gunnar Hellström
>>>   Omnitor
>>>   <mailto:[e-mail]>[e-mail]
>>>   [phone]
>>
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellström
>  Omnitor
>  [e-mail]
>  [phone]


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
This is a nasty, rotten business.
    --Robert L. Crandall, CEO & President of American Airlines