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

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

Den 2017-02-27 kl. 16:34, skrev Randall Gellens:
> 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 hope you are right. I stop arguing about this one.
Thanks
Gunnar
>
>>
>>  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]
>
>

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