Subject: [Slim] Syntax of combination of language tag and Advisory vs Required indication in draft-ietf-slim-negotiating-human-language

From: Gunnar Hellström <[email-masked]>
Date: Thu, 21 Jul 2016 20:08:06 +0200

Randall,

Section 6.3 of draft-ietf-slim-negotiating-human-language-04 says:
"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 
(similar to SIP Accept-Language syntax)."

An example from section 6.5 is

  a=humintlang-send:ase*

I have looked at the syntax description of SIP Accept-Language in RFC 
3261 section 25.1 , and got to the conclusion that the asterisk is used 
in place of a language tag, and not combined with the language tag as 
you have specified it for the slim real-time draft.

So, following that syntax, my interpretation is that we would need a 
syntax according to this example

  a=humintlang-send:*

or, taking inspiration from the Accept-Language syntax, we could change 
the syntax of our attributes and allow enumeration of the language tags 
comma separated and include the asterisk among them.

  a=humintlang-send:ase, *

Of course we could define our own syntax for this parameter, but then we 
should not say that it is similar to the use in Accept-Language, and we 
should double check with the rfc 5646 experts to verify that we can 
append the asterisk on the tag.

Please check this and explain your interpretation, or propose modifications.

/Gunnar

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

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 21 Jul 2016 18:13:09 +0000

> should not say that it is similar to the use in Accept-Language, and we should
> double check with the rfc 5646 experts to verify that we can append the
> asterisk on the tag.

BCP47 (RFC 4647 in this case) defines some different language matching schemes besides that of rfc3261. Of interest here is the concept of "extended language range" which allows for asterisks in a range.

https://tools.ietf.org/html/rfc4647#section-2.2
https://tools.ietf.org/html/rfc4647#section-3.3.2

Addison

Addison Phillips
Principal SDE, I18N Architect (Amazon)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: SLIM [mailto:[email-masked]] On Behalf Of Gunnar Hellström
> Sent: Thursday, July 21, 2016 11:08 AM
> To: [email-masked]
> Subject: [Slim] Syntax of combination of language tag and Advisory vs
> Required indication in draft-ietf-slim-negotiating-human-language
> 
> Randall,
> 
> "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 (similar to SIP
> Accept-Language syntax)."
> 
> 3261 section 25.1 , and got to the conclusion that the asterisk is used in place
> of a language tag, and not combined with the language tag as you have
> specified it for the slim real-time draft.
> 
> So, following that syntax, my interpretation is that we would need a syntax
> according to this example
> 
>   a=humintlang-send:*
> 
> or, taking inspiration from the Accept-Language syntax, we could change the
> syntax of our attributes and allow enumeration of the language tags comma
> separated and include the asterisk among them.
> 
>   a=humintlang-send:ase, *
> 
> should not say that it is similar to the use in Accept-Language, and we should
> double check with the rfc 5646 experts to verify that we can append the
> asterisk on the tag.
> 
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 22 Jul 2016 09:04:29 +0200

What I meant with this topic was to check if our syntax for use of the 
asterisk is safe and non-ambiguous.

And then I discovered that the syntax is not similar to the use in 
Accept-language as the text in 6.3 says. Accept-language has the 
asterisk comma-separated from the language tags ( "en, *" ). I find no 
previous use of an asterisk tacked on directly to the language tag as 
our examples show ( "en*" ).

But since the language tag is alphanumeric, and RFC 4566 allows 
attribute values to be any byte string, the syntax seems allowable. I 
would like other's views on if it is advisable.

The similarity with the Accept-language is not the syntax, but the 
intention of use. The asterisk shows that language-matching does not 
need to be successfully completed for the call to be accepted. The 
reasoning says that that is usually the case anyway.

The syntax is not really logical. The asterisk does not belong to any 
specific language attribute. It would be more logical to have it as an 
attribute value of its own in a separate humintlang attribute. But that 
is less compact.

Another syntax question is if whitespace is allowed before the asterisk. 
SIP says that whitespace is usually allowed around the asterisk, but 
this is an sdp attribute and in RFC 4566 no such habit is documented.

The result is anyway that we need decisions on the questions above and a 
matching formal syntax description.

I assume that a syntax description for the current syntax would be this, 
that we should put in the beginning of 6.5 and call that Syntax and 
examples:

------------------------------------Proposed addition to the beginning 
of 6.5---------------------

6.5 Syntax and examples

The attributes may occur a number of times and follow this syntax:

a=humintlang-send:<language-tag>[<relevance>]

a=humintlang-recv:<language-tag>[<relevance>]

<language-tag> is a language tag according to RFC 4566.

<relevance> is an optional modifier that adds information on the 
relevance of the attribute or a group of attributes. It consists of 
characters not allowed in language tags. One value for <relevance> is 
specified here. It is an asterisk "*" that implies that the call should 
be accepted even if there is no complete language match between the 
offeror and that answering party. Other values of the relevance 
parameter may be defined in other specifications. The order of the 
values within the relevance parameter is not relevant. Whitespace is not 
allowed before and within the relevance parameter. Unrecognized values 
in the relevance parameter shall be ignored.

----------------------------------------------------------------------------------------------------------------------------

In 6.3, the paranthesis

"(similar to SIP Accept-Language syntax)"

should be changed to:

"(similar to the purpose of the use of the asterisk in the SIP 
Accept-Language header )"

----------------------------------------------------------------------------

/Gunnar

Den 2016-07-21 kl. 20:13, skrev Phillips, Addison:
>> To:[email-masked]

---

From: Randall Gellens <[email-masked]>
Date: Fri, 22 Jul 2016 00:34:36 -0700

The feature to add a means to indicate a 
preference to not fail the call, and the asterisk 
notation to do so, was suggested during the 
February 2013 in-person discussion on the 
real-time draft at IETF 86 in Orlando:

>  Advisory vs Required:
>  - Does call fail if no common language?
>  - Define token for use in offer to indicate 
> caller's preference to fail call or not if no 
> common language.
>  - One choice is to say that if the last 
> character of the send-lang or recv-lan value an 
> asterisk, this indicates a request to not fail 
> the call (similar to SIP Accept-Language 
> syntax).  Either way, the called party may 
> ignore this, e.g., for the emergency services 
> use case, a PSAP will likely not fail the call.

We can easily delete the "(similar to SIP 
Accept-Language syntax)" text if that is causing 
heartburn.  I suggest sending a request to do so 
as a WGLC comment.

--Randy

At 9:04 AM +0200 7/22/16, Gunnar Hellström wrote:

>  What I meant with this topic was to check if 
> our syntax for use of the asterisk is safe and 
> non-ambiguous.
>
>  And then I discovered that the syntax is not 
> similar to the use in Accept-language as the 
> text in 6.3 says. Accept-language has the 
> asterisk comma-separated from the language tags 
> ( "en, *" ).  I find no previous use of an 
> asterisk tacked on directly to the language tag 
> as our examples show ( "en*" ).
>
>  But since the language tag is alphanumeric, and 
> RFC 4566 allows attribute values to be any byte 
> string, the syntax seems allowable. I would 
> like other's views on if it is advisable.
>
>  The similarity with the Accept-language is not 
> the syntax, but the intention of use. The 
> asterisk shows that language-matching does not 
> need to be successfully completed for the call 
> to be accepted. The reasoning says that that is 
> usually the case anyway.
>
>  The syntax is not really logical. The asterisk 
> does not belong to any specific language 
> attribute. It would be more logical to have it 
> as an attribute value of its own in a separate 
> humintlang attribute. But that is less compact.
>
>  Another syntax question is if whitespace is 
> allowed before the asterisk. SIP says that 
> whitespace is usually allowed around the 
> asterisk, but this is an sdp attribute and in 
> RFC 4566 no such habit is documented.
>
>  The result is anyway that we need decisions on 
> the questions above and a matching formal 
> syntax description.
>
>  I assume that a syntax description for the 
> current syntax would be this, that we should 
> put in the beginning of 6.5 and call that 
> Syntax and examples:
>
>  ------------------------------------Proposed 
> addition to the beginning of 
> 6.5---------------------
>
>  6.5 Syntax and examples
>
>  <relevance> is an optional modifier that adds 
> information on the relevance of the attribute 
> or a group of attributes. It consists of 
> characters not allowed in language tags. One 
> value for <relevance> is specified here. It is 
> an asterisk "*" that implies that the call 
> should be accepted even if there is no complete 
> language match between the offeror and that 
> answering party. Other values of the relevance 
> parameter may be defined in other 
> specifications. The order of the values within 
> the relevance parameter is not relevant. 
> Whitespace is not allowed before and within the 
> relevance parameter. Unrecognized values in the 
> relevance parameter shall be ignored.
>
> 
>  "(similar to the purpose of the use of the 
> asterisk in the SIP Accept-Language header )"
>
>>  BCP47 (RFC 4647 in this case) defines some 
>> different language matching schemes besides 
>> that of rfc3261. Of interest here is the 
>> concept of "extended language range" which 
>> allows for asterisks in a range.
>>
>> 
>> <https://tools.ietf.org/html/rfc4647#section-2.2>https://tools.ietf.org/html/rfc4647#section-2.2
>> 
>> <https://tools.ietf.org/html/rfc4647#section-3.3.2>https://tools.ietf.org/html/rfc4647#section-3.3.2
>>
>>  Addison
>>
>>  Addison Phillips
>>>  From: SLIM 
>>> [<mailto:[email-masked]>mailto:[email-masked]] 
>>> On Behalf Of Gunnar Hellström
>>>  To: <mailto:[email-masked]>[email-masked]
>>>  values is an asterisk, this indicates a 
>>> request to not fail the call (similar to SIP
>>>  Please check this and explain your 
>>> interpretation, or propose modifications.
>>>
>>>  /Gunnar
>>>
>>>  --
>>>  <mailto:[email-masked]>[email-masked]
>>>  +46 708 204 288
>>>
>>>  <mailto:[email-masked]>[email-masked]
>>> 
>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>
>
>  --
>  <mailto:[email-masked]>[email-masked]
>  +46 708 204 288
>

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
To stay young requires unceasing cultivation of the ability to
unlearn falsehoods.                             --Lazarus Long

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 22 Jul 2016 17:31:21 +0900

On 2016/07/22 16:34, Randall Gellens wrote:
> The feature to add a means to indicate a preference to not fail the
> call, and the asterisk notation to do so, was suggested during the
> February 2013 in-person discussion on the real-time draft at IETF 86 in
> Orlando:
>
>>  Advisory vs Required:
>>  - Define token for use in offer to indicate caller's preference to
>> fail call or not if no common language.
>>  - One choice is to say that if the last character of the send-lang or
>> recv-lan value an asterisk, this indicates a request to not fail the
>> call (similar to SIP Accept-Language syntax).  Either way, the called
>> party may ignore this, e.g., for the emergency services use case, a
>> PSAP will likely not fail the call.
>
> We can easily delete the "(similar to SIP Accept-Language syntax)" text
> if that is causing heartburn.  I suggest sending a request to do so as a
> WGLC comment.

Hello Randy,

Thanks for giving the history of this particular item.

However, I strongly suggest that this be changed so that it matches 
better what other IETF protocols and related specifications do.

If somebody sees something like
a=humintlang-send:en*
there's a big chance they interpret it as "any kind of English", rather 
than as "English, or anything else if that's not available", although as 
far as I understand, according to the current spec, it would be the 
later. Such misunderstandings might happen to anybody who knows HTTP or 
SMTP or SIP or BCP 47, which is a wide range of people.

The current interpretation also makes one think what
a=humintlang-send:en*
a=humintlang-send:es
means. It probably means "English, or anything else if it's not 
available, or Spanish, but don't care to provide anything else if 
Spanish isn't available." This is very subtly, and probably needlessly, 
different from "English, or Spanish, or anything else if these are not 
available" (actually, I have to admit I'm not sure it's different or 
not, but that alone is a bad sign for this design).

Regards,   Martin.

>>  What I meant with this topic was to check if our syntax for use of
>> the asterisk is safe and non-ambiguous.
>>
>> asterisk comma-separated from the language tags ( "en, *" ).  I find
>> no previous use of an asterisk tacked on directly to the language tag
>> attribute value of its own in a separate humintlang attribute. But
>> that is less compact.
>>
>>  Another syntax question is if whitespace is allowed before the
>> asterisk. SIP says that whitespace is usually allowed around the
>> asterisk, but this is an sdp attribute and in RFC 4566 no such habit
>> is documented.
>>
>>  The result is anyway that we need decisions on the questions above
>> and a matching formal syntax description.
>>
>>  I assume that a syntax description for the current syntax would be
>> this, that we should put in the beginning of 6.5 and call that Syntax
>> and examples:
>>
>>  ------------------------------------Proposed addition to the
>> beginning of 6.5---------------------
>>
>>  6.5 Syntax and examples
>>
>> specified here. It is an asterisk "*" that implies that the call
>> should be accepted even if there is no complete language match between
>> the offeror and that answering party. Other values of the relevance
>> values within the relevance parameter is not relevant. Whitespace is
>> not allowed before and within the relevance parameter. Unrecognized
>> values in the relevance parameter shall be ignored.
>>
>>
>>>  BCP47 (RFC 4647 in this case) defines some different language
>>> matching schemes besides that of rfc3261. Of interest here is the
>>> concept of "extended language range" which allows for asterisks in a
>>> range.
>>>
>>>
>>>> [<mailto:[email-masked]>mailto:[email-masked]] On
>>>> Behalf Of Gunnar Hellström

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 22 Jul 2016 13:26:36 +0200

Den 2016-07-22 kl. 10:31, skrev Martin J. Dürst:

> there's a big chance they interpret it as "any kind of English", 
> rather than as "English, or anything else if that's not available", 
> although as far as I understand, according to the current spec, it 
> would be the later. Such misunderstandings might happen to anybody who 
> knows HTTP or SMTP or SIP or BCP 47, which is a wide range of people.
>
> Spanish isn't available." This is very subtly, and probably 
> needlessly, different from "English, or Spanish, or anything else if 
> these are not available" (actually, I have to admit I'm not sure it's 
> different or not, but that alone is a bad sign for this design).
Good point.
How about using a syntax exactly as the Accept-Language for each medium 
and direction.
That will then be a comma separated list, with the asterisk as one 
element if so wanted.

humintlang-send  =  "a=humintlang-send" HCOLON
                      [ language *(COMMA language) ]
language         =  language-range *(SEMI accept-param)
language-range   =  ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" )
accept-param   =  ("q" EQUAL qvalue) / generic-param
qvalue         =  ( "0" [ "." 0*3DIGIT ] )
                   / ( "1" [ "." 0*3("0") ] )
generic-param  =  token [ EQUAL gen-value ]
gen-value      =  token / host / quoted-string

And similarly for humintlang-recv

It is likely more efficient to stick to an already defined format than invent a new.

/Gunnar

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Jul 2016 07:43:13 -0400

+1

---

From: Randall Gellens <[email-masked]>
Date: Fri, 22 Jul 2016 09:37:31 -0700

At 1:26 PM +0200 7/22/16, Gunnar Hellström wrote:

>>  However, I strongly suggest that this be 
>> changed so that it matches better what other 
>> IETF protocols and related specifications do.
>>
>>  there's a big chance they interpret it as "any 
>> kind of English", rather than as "English, or 
>> anything else if that's not available", 
>> although as far as I understand, according to 
>> the current spec, it would be the later. Such 
>> misunderstandings might happen to anybody who 

I do not have tremendous sympathy for people who 
implement without reading the spec.  I also am 
skeptical that modifying the syntax to account 
for misunderstandings by those who don't read the 
spec will he successful, since we cannot 
anticipate all misunderstandings by those who 
don't read the spec.  Especially because the spec 
is not complicated.

>>  means. It probably means "English, or anything 
>> else if it's not available, or Spanish, but 
>> don't care to provide anything else if Spanish 
>> isn't available." This is very subtly, and 
>> probably needlessly, different from "English, 
>> or Spanish, or anything else if these are not 
>> available" (actually, I have to admit I'm not 
>> sure it's different or not, but that alone is 
>> a bad sign for this design).
>>
>  Good point.
>  How about using a syntax exactly as the 
> Accept-Language for each medium and direction.
>  That will then be a comma separated list, with 
> the asterisk as one element if so wanted.
>

This is way more complicated than we need.  Let's 
see if the WG has consensus to make this change.

--Randy

>
>
>  It is likely more efficient to stick to an 
> already defined format than invent a new.
>
>  /Gunnar
>
>
>
>>
>>  Regards,   Martin.
>>
>>>  --Randy
>>>
>>>>> <https://tools.ietf.org/html/rfc4647#section-2.2><https://tools.ietf.org/html/rfc4647#section-2.2><https://tools.ietf.org/html/rfc4647#section-2.2>https://tools.ietf.org/html/rfc4647#section-2.2
>>>>>
>>>>>
>>>>> 
>>>>> <https://tools.ietf.org/html/rfc4647#section-3.3.2><https://tools.ietf.org/html/rfc4647#section-3.3.2><https://tools.ietf.org/html/rfc4647#section-3.3.2>https://tools.ietf.org/html/rfc4647#section-3.3.2
>>>>>
>>>>>
>>>>>   Addison
>>>>>
>>>>>   Addison Phillips
>>>>>> [<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>mailto:[email-masked]] 
>>>>>> On
>>>>>>   To: 
>>>>>> <mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>[email-masked]
>>>>>> <mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>[email-masked]
>>>>>>   +46 708 204 288
>>>>>>
>>>>>> <mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>[email-masked]
>>>>>>
>>>>>> 
>>>>>> <https://www.ietf.org/mailman/listinfo/slim><https://www.ietf.org/mailman/listinfo/slim><https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>>>>
>>>>
>>>>   --
>>>> <mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>[email-masked]
>>>>   +46 708 204 288
>>>>

-------------- Randomly selected tag: ---------------
Nothing is so embarrassing as watching someone do something that you
said couldn't be done.                      --Sam Ewing

---

From: Randall Gellens <[email-masked]>
Date: Fri, 22 Jul 2016 13:07:59 -0700

At 5:31 PM +0900 7/22/16, Martin J. Dürst wrote:

> sure it's different or not, but that alone is a 
> bad sign for this design).
>
>  Regards,   Martin.

Hi Martin,

Personally, I'm not convinced that it's necessary 
to modify the syntax so that people who haven't 
read the spec will not be confused in one 
particular way.  This particular syntax was not 
my idea and I'm not stuck on it, but it was 
suggested by people with very long experience in 
HTTP and SMTP and SIP, so I have to think it 
can't be all that confusing.  I happen to have 
some experience in these areas as well and never 
thought it was confusing in the context of this 
draft.

I would strongly object to replacing it with a 
complex scheme as Gunnar proposed.  I might not 
object if the group wanted to replace it with 
something just as simple as what we have now, 
e.g., using a character other than an asterisk 
("a=humintlang-send:en?"), or using an asterisk 
in lieu of a language tag 
("a=humintlang-send:*"), but would have to ask if 
such a change is worth it, or if someone else 
wouldn't come up with an equal reason to not do 
it that way.

--Randy

-------------- Randomly selected tag: ---------------
razbliuto (ros-blee-OO-toe; Russian; noun): the feeling a person
retains for someone he or she once loved.

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 24 Jul 2016 10:43:18 +0200

Den 2016-07-22 kl. 22:07, skrev Randall Gellens:

>>>>  call (similar to SIP Accept-Language syntax).
Since the comparison with Accept-Language syntax was made already then, 
I guess that the intention was
to use syntax according to this example:
a=humintlang-send: en, *
and
a=humintlang-send: en, fr, es, *

To add the asterisk right on the language-tag could conflict with a 
future revision of the language tag syntax. The asterisk is not defined 
as a delimiter for the language tag.

>>>> Either way, the called
>> would be the later. Such misunderstandings might happen to anybody 
>> who knows HTTP or SMTP or SIP or BCP 47, which is a wide range of 
>> people.
>>
> Personally, I'm not convinced that it's necessary to modify the syntax 
> so that people who haven't read the spec will not be confused in one 
> particular way.  This particular syntax was not my idea and I'm not 
> stuck on it, but it was suggested by people with very long experience 
> in HTTP and SMTP and SIP, so I have to think it can't be all that 
> confusing.  I happen to have some experience in these areas as well 
> and never thought it was confusing in the context of this draft.
>
> I would strongly object to replacing it with a complex scheme as 
> Gunnar proposed.  I might not object if the group wanted to replace it 
> with something just as simple as what we have now, e.g., using a 
> character other than an asterisk ("a=humintlang-send:en?"), or using 
> an asterisk in lieu of a language tag ("a=humintlang-send:*"), but 
> would have to ask if such a change is worth it, or if someone else 
> wouldn't come up with an equal reason to not do it that way.
(GH) Yes, it would make much more sense with a=humintlang-send:*
Or the Accept-Language syntax with a comma separated list of language 
tags, with the asterisk comma separated.

But there are a couple of other things to discuss before we settle it.

*1. The Advisory/Required notation and default.**
*As the text describes the "Advisory" feature, it is a session feature, 
not bound to any specific language or media or direction. So, hooking it 
on to a specific language, media and direction is not logical. And there 
is strong motivation in the text about why the lack of the asterisk 
should not be taken for a "Required" indication. So the "Advisory" state 
is kind of default even when that is what the only value of the feature 
parameter indicates. The logic is quite fuzzy and would need an 
improvement. Most logical would be a session level attribute with "fail 
if no language match is found" as value and "do not fail" as default.
*
**2. Inconvenient notation for majority of cases.*
I think most developers will find the need to specify the majority of 
cases in two very equal attributes (one for send and one for receive) a 
bit space-consuming and awkward. It would feel more natural and save 
characters if we had a common language attribute with a parameter value 
for the direction with send and recv and both as possible values, and 
both as default.
( I have already got this reaction from developers)

*3. Character-expensive notation for call-centers?*
How do we foresee the use of humintlang by multi-language call centers 
when calling out? Will they include a long list of languages, or will 
they call without sdp, and expect the answering part to start providing 
language preferences? If they will provide a long list, it will take 
about 40 characters overhead in SDP per language compared to the 
comma-separated syntax of Accept-Language (if also issue 2 above is 
taken into consideration ).
Should we bother about character-economy in sdp and change to the 
syntax-style of Accept-Language?
*
**4. Accept-Language style notation can be simplified*
When I copied the whole Accept-Language syntax from RFC 3261, there were 
some reactions that it was too complex. It is of course possible to 
delete elements in that syntax and still maintain the structure.
This would be a valid subset ( if we do not do anything to issues 1 and 
2 above):

humintlang-send  =  "a=humintlang-send" HCOLON
                      [ language *(COMMA language) ]
language         =  language-range
language-range   =  ( ( 1*8ALPHA ) / "*" )

*5. Place for relative preference notation**
*Even if the notation for a relative preference across the session is 
not included in this draft, it would be good to have a prepared place 
for it in the notation. It is best linked to a language and a media and 
a direction. So it would suit with a notation like the current specified 
syntax of the use of the asterisk, but with another character. Or as a 
parameter to a language.
In my view, the relative preference is far more important than the 
Advisory/Required feature, that is recommended to have so weak influence 
on call completion decisions.

---------------------

I hope we can have a discussion in the list about these issues before 
conclusions are posted as WGLC issues.

/Gunnar
>>>>>>   double check with the rfc 5646 experts to verify that we can 
>>>>>> append
>>>>>>  the
>>>>>>   asterisk on the tag.
>>>>>>
>>>>>>   "The mechanism for indicating this preference is that, in an 
>>>>>> offer,
>>>>>>  if the last
>>>>>>   syntax of our attributes and allow enumeration of the language 
>>>>>> tags
>>>>>>  comma
>>>>>>   double check with the rfc 5646 experts to verify that we can 
>>>>>> append
>>>>>>  the
>>>>>>   asterisk on the tag.
>>>>>>

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 24 Jul 2016 13:30:16 -0600

Gunnar Hellström wrote:

> Since the comparison with Accept-Language syntax was made already
> then, I guess that the intention was to use syntax according to this
> example:
> a=humintlang-send: en, *
> and
> future revision of the language tag syntax. The asterisk is not
> defined as a delimiter for the language tag.

Unless Gunnar knows something we don't, there is no plan, in the near or 
distant future, to revise the language tag syntax to permit an asterisk 
to be postfixed to any part of a language tag. Such a change could have 
only two effects:

1. create incompatibility with legions of applications which depend on 
the fundamental syntax of "letters and/or digits, separated by hyphens"

2. create confusion with the RFC 4647 use of "*" to mean "any tag" or to 
serve as a wildcard for non-primary subtags

Reading RFC 4647 might be enlightening here.

The proposed syntax "a=humintlang-send: en, fr, es, *" could also cause 
confusion with (2) above, to the extent there is concern about users who 
don't read the spec.

> 1. The Advisory/Required notation and default.
> 2. Inconvenient notation for majority of cases.
> 3. Character-expensive notation for call-centers?
> 4. Accept-Language style notation can be simplified

Gosh, I thought this WG was much farther along than this. It appears 
that elementary syntax decisions are still up for discussion.

--
Doug Ewell | Thornton, CO, US | ewellic.org

---

From: Randall Gellens <[email-masked]>
Date: Tue, 26 Jul 2016 17:35:56 -0700

At 1:30 PM -0600 7/24/16, Doug Ewell wrote:

>  Gosh, I thought this WG was much farther along than this. It 
> appears that elementary syntax decisions are still up for 
> discussion.

Indeed, this topic seemed to be long settled until just now.  It 
hasn't changed since February 2013.

-------------- Randomly selected tag: ---------------
Sorry, no obscene fortunes.  Don't want to offend anyone.
(Now that's obscene!)

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 27 Jul 2016 08:39:23 +0200

> hasn't changed since February 2013.
Yes, all efforts have gone to try to get a satisfying scope, so these 
details of logical and suitable syntax have not been covered.

It would be good to get some responses on the questions earlier in this 
thread.
/Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Wed, 27 Jul 2016 09:54:46 -0700

At 8:39 AM +0200 7/27/16, Gunnar Hellström wrote:

>>>   Gosh, I thought this WG was much farther 
>>> along than this. It appears that elementary 
>>> syntax decisions are still up for discussion.
>>
>>  Indeed, this topic seemed to be long settled 
>> until just now.  It hasn't changed since 
>> February 2013.
>>
>  Yes, all efforts have gone to try to get a 
> satisfying scope, so these details of logical 
> and suitable syntax have not been covered.
>
>  It would be good to get some responses on the 
> questions earlier in this thread.
>  /Gunnar

Hi Gunnar,

I did respond to the issues you raised.  I've 
responded several times, most recently on 22 July:

At 1:07 PM -0700 7/22/16, Randall Gellens wrote:
>  Personally, I'm not convinced that it's 
> necessary to modify the syntax so that people 
> who haven't read the spec will not be confused 
> in one particular way.  This particular syntax 
> was not my idea and I'm not stuck on it, but it 
> was suggested by people with very long 
> experience in HTTP and SMTP and SIP, so I have 
> to think it can't be all that confusing.  I 
> happen to have some experience in these areas 
> as well and never thought it was confusing in 
> the context of this draft.
>
> ("a=humintlang-send:*"), but would have to ask 
> if such a change is worth it, or if someone 
> else wouldn't come up with an equal reason to 
> not do it that way.

To make a change, we would need WG consensus on a 
specific proposal.  Probably the best way to 
proceed is to first determine if others in the WG 
agree that there is a problem with the current 
syntax.  If the group feels there is a problem, 
then we can have one or a small number of 
specific proposal and see if there is consensus 
to proceed.  If the group does not feel there is 
a problem, then we do not make a change.

-------------- Randomly selected tag: ---------------
Majority: That quality that distinguishes a crime from a law.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Jul 2016 13:20:27 -0400

On 7/27/16 12:54 PM, Randall Gellens wrote:

> To make a change, we would need WG consensus on a specific proposal.
> Probably the best way to proceed is to first determine if others in the
> WG agree that there is a problem with the current syntax.  If the group
> feels there is a problem, then we can have one or a small number of
> specific proposal and see if there is consensus to proceed.  If the
> group does not feel there is a problem, then we do not make a change.

Currently the syntax is only loosely defined in text. At the very least 
is needs to be fully defined. IMO this should be done using the template 
for attribute definitions introduced in rfc4566bis.

Also, as Gunnar already mentioned, the semantics are not clear when "*" 
is present. Is "*" valid with both -send and -recv? If so, it must mean 
something different in each.

Further, does the "*" only qualify the language and direction to which 
it is attached, or does it qualify the overall negotiation of the 
associated media stream, or of the call as a whole?

And how does this relate to O/A? What is the point of indicating 
optionality in an *answer*? At that point the media stream is already 
set up. (Or rejected.)

Setting aside q-values for now, Gunnar's proposal isn't significantly 
more complex than the current proposal. It does detach the "*" from the 
language indication. Whether that is a good thing or not depends on the 
resolution of my issues above. What his proposal does is make the 
indication of multiple languages more concise. It *may*  complicate the 
specification of O/A behavior.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Wed, 27 Jul 2016 16:19:02 -0700

At 1:20 PM -0400 7/27/16, Paul Kyzivat wrote:

>  Currently the syntax is only loosely defined in text. At the very 
> least is needs to be fully defined. IMO this should be done using 
> the template for attribute definitions introduced in rfc4566bis.

Here is the current 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 (similar to SIP Accept-Language syntax).  Either way, the called
    party MAY ignore this, e.g., for the emergency services use case, a
    PSAP will likely not fail the call.

In what way is this confusing or vague or incompletely specified? 
I'd be happy to delete the parenthesized aside "(similar to SIP 
Accept-Language syntax)" as that seems to be wrong and/or confusing. 
Since we're in WGLC we'd need to open a ticket for this.

>  Also, as Gunnar already mentioned, the semantics are not clear when 
> "*" is present. Is "*" valid with both -send and -recv? If so, it 
> must mean something different in each.

I'm confused as to where the confusion is coming from.  My reading of 
the text is that it is very clear that an asterisk is permitted in 
any value of either attribute in any media, and that it is a binary 
meaning: if the asterisk is present anywhere, it means "please do not 
fail the call even if no matches can be made."  I don't see the basis 
for the idea that "it must mean something different in each."

>
>  Further, does the "*" only qualify the language and direction to 
> which it is attached, or does it qualify the overall negotiation of 
> the associated media stream, or of the call as a whole?

Again, I'm puzzled.  My reading of the text is that it clearly says 
an asterisk as the last character of ANY value (of any media in 
either direction) applies to the entire dialog.

> optionality in an *answer*? At that point the media stream is 
> already set up. (Or rejected.)

Again, the text seems very clear to me, so I don't understand why 
there is any confusion.  It says "in an offer."  Obviously it doesn't 
make sense in an answer.

>  Setting aside q-values for now, Gunnar's proposal isn't 
> significantly more complex than the current proposal. It does 
> detach the "*" from the language indication. Whether that is a good 
> thing or not depends on the resolution of my issues above. What his 
> proposal does is make the indication of multiple languages more 
> concise. It *may*  complicate the specification of O/A behavior.

As I see it, it introduces a level of complexity that we don't need. 
As I've said several times, neither the idea for a means to indicate 
a preference to not fail the call, nor the asterisk syntax to 
indicate it, were my own; I have no personal stake in it, but I do 
want to get this draft completed.  The asterisk has been there since 
early 2013 with no one finding it confusing.  If the group wants to 
change it now, that's fine, but I want to move forward and get the 
draft done.

-------------- Randomly selected tag: ---------------
"Contrariwise," continued Tweedledee, "if it was so, it might
be, and if it were so, it would be; but as it isn't, it ain't. That's
logic!"

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 28 Jul 2016 11:29:01 +0200

Den 2016-07-28 kl. 01:19, skrev Randall Gellens:
>> least is needs to be fully defined. IMO this should be done using the 
>> template for attribute definitions introduced in rfc4566bis.
>
> In what way is this confusing or vague or incompletely specified? I'd 
> be happy to delete the parenthesized aside "(similar to SIP 
GH: We clearly need a proper syntax definition. It needs to be clearly 
seen for the parsing algorithm that there is a need to detach an 
optional parameter at the end of the language tag ( if this syntax is 
maintained ) and it needs to be explicitly stated if it is allowed to 
include this parameter also in the answer, even if it is meaningless.

The draft has the confusion clearly stated. In 6.2 it is first said " 
Each value MUST be a language tag per RFC 5646"
Then it is said: "In an offer, each language tag value MAY have an 
asterisk appended as
    the last character (after the registry value)."
So, the value is both defined to be only the language tag and the 
language tag with the asterisk appended that needs to be detached to get 
the value. I hope you see the lack of stringency and that you want to 
get this clearly defined.

And, yes, since we discovered that it has no similarity to the 
Accept-Language syntax, that paranthesis must be deleted.  The fact that 
it has survived so long may indicate that people (as in my case) have 
bothered about more fundamental factors in this draft than the proposed 
syntax for the dont-fail-the-call feature that is anyway kind of default.
> the text is that it is very clear that an asterisk is permitted in any 
> value of either attribute in any media, and that it is a binary 
> Again, I'm puzzled.  My reading of the text is that it clearly says an 
> asterisk as the last character of ANY value (of any media in either 
> direction) applies to the entire dialog.
>
>>
GH: It is true that you find the answers on these three questions in the 
text. But there is no logic behind the answers. Usually, when you hook a 
parameter to an attribute value, the parameter has a relation to just 
that value. But here there is no such relation. The parameter is a 
session parameter that apparently means "do not fail the call because of 
language matching reasons", and is not specific for language, media and 
direction, but it is said that it can be hooked on to a language and 
media and direction specific attribute value.
I recently also felt a reason to ask you what the intention was and got 
that interpretation confirmed. It is just so unusual placement of a 
parameter that it is worth sorting out the syntax for this reason.

>> significantly more complex than the current proposal. It does detach 
>> the "*" from the language indication. Whether that is a good thing or 
>> not depends on the resolution of my issues above. What his proposal 
>> does is make the indication of multiple languages more concise. It 
>> *may*  complicate the specification of O/A behavior.
>
> As I've said several times, neither the idea for a means to indicate a 
> preference to not fail the call, nor the asterisk syntax to indicate 
> it, were my own; I have no personal stake in it, but I do want to get 
> this draft completed.  The asterisk has been there since early 2013 
> with no one finding it confusing.  If the group wants to change it 
> now, that's fine, but I want to move forward and get the draft done.
GH: Since the most useful default value is to not fail the call on 
language matching reasons, we should probably swap the meaning of the 
parameter to mean "I suggest that you fail the call if you cannot match 
my languages". Then the most common implementations do not need to set it.
As you have described it, it is used as a session attribute. So then it 
should really be specified as a session attribute to not cause 
confusion. E.g. "a=humintlang: reject"  on session level in the offer.  
If also the other value should have an explicit value, it could be "accept".

GH: I see much more use of a parameter value for highest preferred 
language to be attached to the media and direction and language. A plus 
character "+" would be suitable, and a way to attach it to the 
language(s) that are most highly preferred to be used in the session. 
Not more than one per media and direction would be allowed. If more than 
one for the same direction but different media are specified, it means a 
strong preference for getting both these languages presented 
simultaneously ( e.g. see the person who is speaking, because you have 
very good use of lip-reading. )  Not satisfying these preference 
indications should not cause media or call to be rejected, but only used 
as a preference indication for the other party to try to match. I 
hesitate to propose the syntax of a character appended to the language 
tag, but in this case the placement of the parameter there would at 
least be the logical place.

GH: I repeat the questions I placed recently, with my indications of 
where we are now with them.
<Discussed above including a session level proposal>
<Not covered, no answer yet>

*<*No answer yet>

And similarly for humintlang-recv
<This gets rid of the complexity, but still places the do-not-fail parameter on the media level, and that requires us to define a meaning for that placement>

<Discussed above, with a placement, a character, but not a complete 
syntax proposal.>

Regards
Gunnar

---------------------

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Jul 2016 11:42:04 -0400

Inline

> In what way is this confusing or vague or incompletely specified?

There is no ABNF syntax for the value.

> I'd be
> happy to delete the parenthesized aside "(similar to SIP Accept-Language
> syntax)" as that seems to be wrong and/or confusing. Since we're in WGLC
> we'd need to open a ticket for this.

Since there is no apparent relationship to Accept-Language I agree this 
should be removed.

>> "*" is present. Is "*" valid with both -send and -recv? If so, it must
>> mean something different in each.
>
> value of either attribute in any media, and that it is a binary meaning:
> if the asterisk is present anywhere, it means "please do not fail the
> call even if no matches can be made."  I don't see the basis for the
> idea that "it must mean something different in each."

I failed to notice the reference to "in an offer" when making my prior 
reply. So some of my comments are invalid.

But this is still confusing to me. I guess you are assuming that the 
answerer might "fail the call" due to the presence of these attributes, 
and the * is a request not to do that. But I think this deserves more 
discussion of what actions the answerer might take and under what 
circumstances. Failing the call is pretty extreme. It is also possible 
to reject a media stream. Is the * also intended to affect that?

> direction) applies to the entire dialog.

Yes, I realize it says that. But I am confused because that makes little 
sense to me. If it doesn't pertain to the particular value it is 
attached to, then the syntax seems inappropriate to the task. And 
further, it could be useful to have it apply to a particular value.

To be specific, is there any semantic difference between:

1)    a=humintlang-send:es
       a=humintlang-send:en*

2)    a=humintlang-send:es*
       a=humintlang-send:en

> Again, the text seems very clear to me, so I don't understand why there
> is any confusion.  It says "in an offer."  Obviously it doesn't make
> sense in an answer.

Is it *allowed* in an answer, even if it doesn't make sense?

>> more complex than the current proposal. It does detach the "*" from
>> the language indication. Whether that is a good thing or not depends
>> on the resolution of my issues above. What his proposal does is make
>> the indication of multiple languages more concise. It *may*
>> complicate the specification of O/A behavior.
>
> As I see it, it introduces a level of complexity that we don't need. As
> I've said several times, neither the idea for a means to indicate a
> preference to not fail the call, nor the asterisk syntax to indicate it,
> were my own; I have no personal stake in it, but I do want to get this
> draft completed.  The asterisk has been there since early 2013 with no
> one finding it confusing.  If the group wants to change it now, that's
> fine, but I want to move forward and get the draft done.

When working on drafts, I find that it is often counterproductive to 
raise issues about details until one has agreement on the concepts. 
Since there has been raging controversy over concepts (in particular, 
relationships between languages in different media) I didn't want to 
distract from that.

Now that we are past that, it is important to get the more detailed 
aspects right.

Since this draft defines new SDP attributes the SDP directorate will be 
asked to review it. I happen to be on the directorate, and so can 
anticipate what issues will be raised. As part of rfc4566bis there is an 
effort to tighten up and standardize the way attribute syntax is 
defined. You can look at rfc4566bis to see how that is now being done. 
In involves ABNF syntax for the attribute value.

Also, it is now expected that every new attribute definition come with 
specific language defining offer/answer behavior. That also needs to be 
present.

Having raised these issues, I didn't bother (yet) raising lesser issues. 
I will do a complete, nit-picky, review once the more significant issues 
are sorted out.

I realize you want this to be done. But it isn't done yet.

	Thanks,
	Paul