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

From: [email-masked]
Date: Thu, 02 Feb 2017 10:17:58 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Selection of Language for Internet Media of the IETF.

        Title           : Negotiating Human Language in Real-Time Communications
        Author          : Randall Gellens
	Filename        : draft-ietf-slim-negotiating-human-language-06.txt
	Pages           : 19
	Date            : 2017-02-02

Abstract:
   Users have various human (natural) language needs, abilities, and
   preferences regarding spoken, written, and signed languages.  When
   establishing interactive communication ("calls") there needs to be a
   way to negotiate (communicate and match) the caller's language and
   media needs with the capabilities of the called party.  This is
   especially important with emergency calls, where a call can be
   handled by a call taker capable of communicating with the user, or a
   translator or relay operator can be bridged into the call during
   setup, but this applies to non-emergency calls as well (as an
   example, when calling a company call center).

   This document describes the need and a solution using new SDP stream
   attributes.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 2 Feb 2017 13:59:38 -0500

There is a lot of repeated material in section 6. It looks like an 
editing error.

	Thanks,
	Paul

On 2/2/17 1:17 PM, [email-masked] wrote:
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim
>

---

From: Randall Gellens <[email-masked]>
Date: Thu, 2 Feb 2017 16:20:10 -0800

>  There is a lot of repeated material in section 6. It looks like an 

Are you talking about the two tables, one per attribute?  I think 
that's a consequence of switching to the larger table template.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Don't accept your dog's admiration as conclusive evidence that you are
wonderful.                                               --Ann Landers

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 3 Feb 2017 12:26:55 -0500

On 2/2/17 7:20 PM, Randall Gellens wrote:
> Are you talking about the two tables, one per attribute?  I think that's
> a consequence of switching to the larger table template.

Oh, duh. Sorry.

IMO you only need to supply the common syntax once, and reference it in 
the other place. Also, you are missing a reference to the value syntax. 
I suggest:

    Contact Name:  Randall Gellens
    Contact Email Address:  [email-masked]
    Attribute Name:  humintlang-recv
    Attribute Value: humintlang-value
    Attribute Syntax:

       humintlang-value =  Language-Tag [ asterisk ]
                           ; Language-Tag defined in RFC 5646
       asterisk         =  "*"

    Attribute Semantics:  Described in Section 5.2 of TBD: THIS DOCUMENT
    Usage Level:  media
    Charset Dependent:  No
    Purpose:  See Section 5.2 of TBD: THIS DOCUMENT
    O/A Procedures:  See Section 5.2 of TBD: THIS DOCUMENT
    Reference:  TBD: THIS DOCUMENT

    Contact Name:  Randall Gellens
    Contact Email Address:  [email-masked]
    Attribute Name:  humintlang-send
    Attribute Value: humintlang-value
    Attribute Syntax: see above
    Attribute Semantics:  Described in Section 5.2 of TBD: THIS DOCUMENT
    Usage Level:  media
    Charset Dependent:  No
    Purpose:  See Section 5.2 of TBD: THIS DOCUMENT
    O/A Procedures:  See Section 5.2 of TBD: THIS DOCUMENT
    Reference:  TBD: THIS DOCUMENT

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 6 Feb 2017 00:54:41 +0100

Randall,

It is good to see the issues acted on.

1. I see that issues #2, #3, #4, #13 are completely done.

2. For #15, the use of BCP 47 instead of RFC 5646, I saw that you had 
problems with xml2rfc if you tried to consistently use BCP 47, so 
therefore it is a mix now and I assume that that will be acceptable.

3. For #6 about the attribute registration form, I wonder if it is still 
accepted to not use the RFC 4566 bis format?
And if it is accepted, what is the procedure for adding RFC 4566bis 
format registration afterwards?
(The reason for my question is that we will very soon need the WEBRTC 
specific values specified.)

4. I wonder if the syntax for the asterisk in the values is sufficiently 
strictly specified.

In the beginning of 5.2, the attributes are described with something 
looking as a syntax description:

       a=humintlang-send:<language tag>
       a=humintlang-recv:<language tag>

Later it is said:

  Each value MUST be a language tag perBCP 47 <https://tools.ietf.org/html/bcp47>  [RFC5646 <https://tools.ietf.org/html/rfc5646>].

Then it is said:
"In an offer, each language tag value MAY have an asterisk appended as
    the last character (after the language tag)."

In 6. we have:
"Attribute Syntax:

       humintlang-value =  Language-Tag [ asterisk ]
                           ; Language-Tag defined inRFC 5646 <https://tools.ietf.org/html/rfc5646>
       asterisk         =  "*"
"

It seems to me that sometimes the wording indicates that the
asterisk is included in the language tag and sometimes appended to the language tag.
I think this can be made clearer if the asterisk is mentioned already in the first
syntax indication, maybe something like this:

       a=humintlang-send:<language tag>[call completion option]
       a=humintlang-recv:<language tag>[call completion option]

5. A syntax question: Does the syntax description in chapter 6
require that the asterisk follows without whitespace after the language tag?

6. We discussed earlier if the unusual syntax of the asterisk really would be
accepted when the attribute shall be reviewed and registered. It is really
a kind of session parameter that can be hooked on many times on media level attributes.
Was the way we use it assured to be acceptable by the coming registration review?

Regards

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

Den 2017-02-03 kl. 18:26, skrev Paul Kyzivat:
> IMO you only need to supply the common syntax once, and reference it 
> in the other place. Also, you are missing a reference to the value 
> syntax. I suggest:
>
>>>>      Filename        : 
>>>> draft-ietf-slim-negotiating-human-language-06.txt
>>>>      Pages           : 19
>>>>      Date            : 2017-02-02
>>>>
>>>>  Abstract:

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

---

From: Randall Gellens <[email-masked]>
Date: Sun, 5 Feb 2017 16:55:15 -0800

At 12:54 AM +0100 2/6/17, Gunnar Hellström wrote:

>  2. For #15, the use of BCP 47 instead of RFC 
> 5646, I saw that you had problems with xml2rfc 
> if you tried to consistently use BCP 47, so 
>  3. For #6 about the attribute registration 
> form, I wonder if it is still accepted to not 
> use the RFC 4566 bis format?
>  And if it is accepted, what is the procedure 
> for adding RFC 4566bis format registration 
> afterwards?
>  (The reason for my question is that we will 
> very soon need the WEBRTC specific values 
> specified.)

4566-bis is an expired draft, not an RFC, so it 
is not normative.  However, I have adopted a 
format that is virtually identical to it, only 
omitting one completely redundant field.  I think 
for the post-LC revision of the draft, I might 
rearrange it to put the attribute name first 
rather than the contact name, to avoid confusion.

>
>
>  4. I wonder if the syntax for the asterisk in 
> the values is sufficiently strictly specified.
>
>  In the beginning of 5.2, the attributes are 
> described with something looking as a syntax 
> description:
>
>   Each value MUST be a language tag per 
> <https://tools.ietf.org/html/bcp47>BCP 47 
> [<https://tools.ietf.org/html/rfc5646>RFC5646].
>
>  Then it is said:
>                            ; Language-Tag 
> defined in 
> <https://tools.ietf.org/html/rfc5646>RFC 5646
>        asterisk         =  "*"
>  "
>
>  I think this can be made clearer if the 
> asterisk is mentioned already in the first

The syntax is specified in ABNF.  It indicates 
that a language tag is required and an asterisk 
may optionally be appended.  I believe this is 
consistent with the text.

>  require that the asterisk follows without whitespace after the language tag?

The ABNF rules in RFC 5234 do not include 
implicit white space, so the asterisk must 
immediately follow the language tag.

> by the coming registration review?

I am not aware of any objections.

--Randall

>  <mailto:[email-masked]>[email-masked]
>  +46 708 204 288
>
>
>
>
>
>
>
>
>
>>  IMO you only need to supply the common syntax 
>> once, and reference it in the other place. 
>> Also, you are missing a reference to the value 
>> syntax. I suggest:
>>
>>  Contact Email Address: 
>> <mailto:[email-masked]>[email-masked]
>>  Contact Email Address: 
>> <mailto:[email-masked]>[email-masked]
>>>>  On 2/2/17 1:17 PM, 
>>>> <mailto:[email-masked]>[email-masked] 
>>>> wrote:
>>>>
>>>>>
>>>>> <https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/>https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/
>>>>>
>>>>>
>>>>> <https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-06>https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-06
>>>>>
>>>>>
>>>>> <https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-06>https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-06
>>>>>
>>>>>
>>>>>
>>>>>  <ftp://ftp.ietf.org/internet-drafts/>ftp://ftp.ietf.org/internet-drafts/
>>>>>
>>>>>  <mailto:[email-masked]>[email-masked]
>>>>> 
>>>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>>>
>>>>
>>>>  <mailto:[email-masked]>[email-masked]
>>>> 
>>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>>
>>>
>>>
>>
>>  <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
>

-------------- Randomly selected tag: ---------------
One forgets words as one forgets names.  One's vocabulary needs
constant fertilization or it will die.      --Evelyn Waugh

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 6 Feb 2017 09:11:12 +0100

Den 2017-02-06 kl. 01:55, skrev Randall Gellens:
>>  2. For #15, the use of BCP 47 instead of RFC 5646, I saw that you 
>> had problems with xml2rfc if you tried to consistently use BCP 47, so 
>>  3. For #6 about the attribute registration form, I wonder if it is 
>> still accepted to not use the RFC 4566 bis format?
>>  (The reason for my question is that we will very soon need the 
>> WEBRTC specific values specified.)
>
> 4566-bis is an expired draft, not an RFC, so it is not normative. 
> However, I have adopted a format that is virtually identical to it, 
> only omitting one completely redundant field.  I think for the post-LC 
> revision of the draft, I might rearrange it to put the attribute name 
> first rather than the contact name, to avoid confusion.
4566bis-18 was published last Saturday.
The form contains for "Usage level", the dcsa(subprotocol) value that 
will be used for real-time text.
It also contains a Mux category that should have a  regular value.
I agree that these are from drafts and I think we need guidance from 
IANA if it is appropriate to include them.
>
>>
>>
>>  4. I wonder if the syntax for the asterisk in the values is 
>> sufficiently strictly specified.
>>
>>                            ; Language-Tag defined in 
> The syntax is specified in ABNF.  It indicates that a language tag is 
> required and an asterisk may optionally be appended.  I believe this 
> is consistent with the text.
But the first appearance early in 5.2 also looks as a syntax description 
in ABNF, and it does not include the asterisk.
And the language goes back and forth between saying that the asterisk is 
included in the language tag ( which is not true) and saying that it is 
appended ( that is not shown in the first syntax description ).
Readers can possibly figure out now when we have the examples, but the 
description is not exactly clean.
> The ABNF rules in RFC 5234 do not include implicit white space, so the 
> asterisk must immediately follow the language tag.
>
>>
Paul indicated on 2016-07-28 that once the main issues were sorted out, 
a better analysis can be done to see if it can be registered by IANA, 
and took some examples of what can be seen as unclear or not appropriate 
with the current use of the asterisk. I think we have reached that stage 
now.
Having the asterisk placed on the media level should have some meaning 
but it currently has only session level influence. I can provide 
proposals for media level influence so that it possibly can stay as a 
media level value.

Gunnar
>>>> that's
>>>  IMO you only need to supply the common syntax once, and reference 
>>> it in the other place. Also, you are missing a reference to the 
>>> value syntax. I suggest:
>>>
>>>>> <mailto:[email-masked]>[email-masked] wrote:
>>>>>
>>>>>>