Subject: Re: [Slim] Collapse attribute syntax to one line in draft-ietf-slim-negotiating-human-language

From: Natasha Rooney <[email-masked]>
Date: Thu, 1 Jun 2017 09:54:21 +0000

This seems sufficient given our previous conversations. q-values can be applied within further work (although I don’t see why ordering doesn’t do the job, works in web).

Bernard - any further thoughts?

Natasha Rooney | Internet Engineering Director | Internet and Web Team | Technology | GSMA | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>

On 30 May 2017, at 00:04, Randall Gellens <[email-masked]<mailto:[email-masked]>> wrote:

I uploaded version -10, which includes the syntax change to single line, along with a few editorial clarifications.  (Version -09 accidently omitted an editorial clarification.)

You can see a diff of the changes from 08 to 10 here:
https://www.ietf.org/rfcdiff?url1=draft-ietf-slim-negotiating-human-language-08&url2=draft-ietf-slim-negotiating-human-language-10

If there objections to the change from multi-line to single-line, this can be reverted.

--Randy

At 2:57 PM -0700 5/28/17, Randall Gellens wrote:

In response to Adam Roach's comments as well as other comments, I intend to update the draft to collapse the attribute syntax to one line; each attribute can occur at most once per media, with all languages on the same line.  This will further reduce the size of the SDP block.

If you object to this, please reply.

Here is the section of Adam's review:

At 8:31 PM +0000 3/28/17, Sabrina Tanamal via RT wrote:
 I'll note that much of this can be fixed if the syntax is collapsed so
 that each media section can have at most one hlang-send and one
 hlang-receive, each of which contain a list of one or more languages
 that can be sent or received. This is also much more consistent with the
 way SDP attributes are used in general. The presence of a "*" token on
 that line would indicate the "call should happen even without matching
 languages" characteristic; since there is only one place to add this
 indicator, the ambiguity of some lines indicating it and others not
 disappears. The preceding example would collapse to:

 m=audio 49250 RTP/AVP 20
 a=hlang-send:es eu en *
 a=hlang-recv:es eu en *

 ...and the example text would be revised to remove the implication that
 *sending* "es" necessarily implies *receiving* "es".

 I'll further note that the majority of SDP libraries I've worked with
 would make accessing the all-on-one-line format easier than
 one-line-per-language as well.

Here is the proposed ABNF:

   Attribute Syntax:

      hlang-value =  Language-Tag *( SP Language-tag ) [ SP asterisk ]

                           ; Language-Tag as defined in BCP 47

      asterisk    =  "*"   ; an asterisk (ASCII %2A) character

      sp          =  1*" " ; one or more ASCII space (%20) characters

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
If forced to travel on an airplane, try and get in the cabin with
the Captain, so you can keep an eye on him and nudge him if he
falls asleep or point out any mountains looming up ahead ...
       --Mike Harding, The Armchair Anarchist's Almanac.

_______________________________________________
SLIM mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/slim

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Knowledge always desires increase; it is like fire, which must
first be kindled by some external agent, but which will afterwards
propagate itself.                       --Dr. Samuel Johnson

_______________________________________________
SLIM mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/slim

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

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 1 Jun 2017 16:33:25 +0200

Den 2017-06-01 kl. 11:54, skrev Natasha Rooney:
> This seems sufficient given our previous conversations. q-values can 
> be applied within further work (although I don’t see why ordering 
> doesn’t do the job, works in web). 
It is not feasible to change syntax by adding q-values in an extension. 
That will cause interop problems, or complicated needs to negotiate 
protocol version. So, we need to decide the syntax now and stick closely 
to it.

Ordering is not sufficient because we have a need to set preferences 
between different media.
Ordering only works within a media.

And, a minor drawback: ordering does not allow to specify a number of 
languages in the same media with the same preference. One always will 
look as if it is more preferred than another. - but I think we can live 
with that.

Maybe the main question is: Will our own one-line syntax really be less 
complex to parse than the Accept-Language syntax that we might be able 
to find ready library routines for?
Adam Roach had views on complexity to parse different solutions. Maybe 
you, Adam can have a view on this?

Regards

Gunnar

> Natasha Rooney | Internet Engineering Director | Internet and Web Team 
> | Technology | GSMA | [email-masked] <mailto:[email-masked]> | +44 
> (0) 7730 219 765 | @thisNatasha | Skype: [email-masked] 
> <mailto:[email-masked]>
>
>> On 30 May 2017, at 00:04, Randall Gellens <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> I uploaded version -10, which includes the syntax change to single 
>> line, along with a few editorial clarifications.  (Version -09 
>> accidently omitted an editorial clarification.)
>>
>>> In response to Adam Roach's comments as well as other comments, I 
>>> intend to update the draft to collapse the attribute syntax to one 
>>> line; each attribute can occur at most once per media, with all 
>>> languages on the same line.  This will further reduce the size of 
>>> the SDP block.
>>>
> This email and its attachments are intended for the above named only 
> and may be confidential. If they have come to you in error you must 
> take no action based on them, nor must you copy or show them to 
> anyone; please reply to this email or call +44 207 356 0600 and 
> highlight the error.
>
>
>

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

---

From: Randall Gellens <[email-masked]>
Date: Thu, 1 Jun 2017 10:17:05 -0700

The group has repeatedly discussed q-values and 
priority and has always decided to not go down 
that path.

At 4:33 PM +0200 6/1/17, Gunnar Hellström wrote:

>>  This seems sufficient given our previous 
>> conversations. q-values can be applied within 
>> further work (although I don't see why 
>> ordering doesn't do the job, works in web).
>>
>  It is not feasible to change syntax by adding 
> q-values in an extension. That will cause 
> interop problems, or complicated needs to 
> negotiate protocol version. So, we need to 
> decide the syntax now and stick closely to it.
>
>  Ordering is not sufficient because we have a 
> need to set preferences between different media.
>  And, a minor drawback: ordering does not allow 
> to specify a number of languages in the same 
> media with the same preference. One always will 
> look as if it is more preferred than another. - 
> but I think we can live with that.
>
>  Maybe the main question is: Will our own 
> one-line syntax really be less complex to parse 
> than the Accept-Language syntax that we might 
> be able to find ready library routines for?
>  Adam Roach had views on complexity to parse 
> different solutions. Maybe you, Adam can have a 
> view on this?
>
>  Regards
>
>  Gunnar
>
>>
>>  Natasha Rooney | Internet Engineering Director 
>> | Internet and Web Team | Technology | GSMA | 
>> <mailto:[email-masked]>[email-masked] | 
>> +44 (0) 7730 219 765 | @thisNatasha | Skype: 
>> <mailto:[email-masked]>[email-masked]
>>
>>>  On 30 May 2017, at 00:04, Randall Gellens 
>>> <<mailto:[email-masked]>[email-masked]> 
>>> wrote:
>>>
>>>  I uploaded version -10, which includes the 
>>> syntax change to single line, along with a 
>>> few editorial clarifications. (Version -09 
>>> <https://www.ietf.org/rfcdiff?url1=draft-ietf-slim-negotiating-human-language-08&url2=draft-ietf-slim-negotiating-human-language-10>https://www.ietf.org/rfcdiff?url1=draft-ietf-slim-negotiating-human-language-08&url2=draft-ietf-slim-negotiating-human-language-10
>>>
>>>  If there objections to the change from 
>>> multi-line to single-line, this can be 
>>> reverted.
>>>
>>>  --Randy
>>>
>>>
>>>
>>>>  In response to Adam Roach's comments as well 
>>>> as other comments, I intend to update the 
>>>> draft to collapse the attribute syntax to 
>>>> one line; each attribute can occur at most 
>>>> once per media, with all languages on the 
>>>> same line. This will further reduce the size 
>>>> of the SDP block.
>>>>
>>>>  <mailto:[email-masked]>[email-masked]
>>>> 
>>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>>
>>>
>>>
>>>  --
>>>  Randall Gellens
>>>  <mailto:[email-masked]>[email-masked]
>>> 
>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>
>>
>>  This email and its attachments are intended 
>> for the above named only and may be 
>> confidential. If they have come to you in 
>> error you must take no action based on them, 
>> nor must you copy or show them to anyone; 
>> please reply to this email or call +44 207 356 
>> 0600 and highlight the error.
>>
>>
>>
>>  <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: ---------------
Snacktrek, n.:
    The peculiar habit, when searching for a snack, of constantly
returning to the refrigerator in hopes that something new will have
materialized.                                --Rich Hall, "Sniglets"

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 1 Jun 2017 20:01:15 +0200

Den 2017-06-01 kl. 19:17, skrev Randall Gellens:
> The group has repeatedly discussed q-values and priority and has 
> always decided to not go down that path.
I expect our shepherd to lead us to the decision. We had one reviewer 
requesting us to use the Accept-Language syntax with the q-values.

I can accept either way, either the one-line syntax used in version -10, 
or the Accept-Language syntax.

If we go with the current one-line syntax, I will propose to add the 
preference between modalities by giving the asterisk a preference 
interpretation on media level.
And I will propose to use the -t language subtag for simultaneous 
languages in other modalities.
This may lack some flexibility but will likely be sufficient.

If we go with the Accept-Language syntax, then I will propose to let the 
q-values have scope over the whole SDP in order to assign preference 
between modalities,
and I will propose to let equal q-values or q-values within a narrow 
interval to indicate a preference for using simultaneous languages in 
different media.  The first item is nice and flexible, the second, for 
simultaneity may be less elegant.

I hope you will accept either solution. And do it already in the current 
draft.

So we just need the decision on the Accept-Language syntax proposal and 
then move on.

Regards

Gunnar

>>>  This seems sufficient given our previous conversations. q-values 
>>> can be applied within further work (although I don't see why 
>>  It is not feasible to change syntax by adding q-values in an 
>> extension. That will cause interop problems, or complicated needs to 
>> negotiate protocol version. So, we need to decide the syntax now and 
>> stick closely to it.
>>
>>  And, a minor drawback: ordering does not allow to specify a number 
>> of languages in the same media with the same preference. One always 
>> will look as if it is more preferred than another. - but I think we 
>> can live with that.
>>
>>  Maybe the main question is: Will our own one-line syntax really be 
>> less complex to parse than the Accept-Language syntax that we might 
>>  Adam Roach had views on complexity to parse different solutions. 
>> Maybe you, Adam can have a view on this?
>>
>>  Regards
>>
>>  Gunnar
>>
>>>
>>>  Natasha Rooney | Internet Engineering Director | Internet and Web 
>>> Team | Technology | GSMA | <mailto:[email-masked]>[email-masked] 
>>> | +44 (0) 7730 219 765 | @thisNatasha | Skype: 
>>>> <<mailto:[email-masked]>[email-masked]> wrote:
>>>>
>>>  This email and its attachments are intended for the above named 
>>> only and may be confidential. If they have come to you in error you 
>>> must take no action based on them, nor must you copy or show them to

---

From: Brian Rosen <[email-masked]>
Date: Thu, 1 Jun 2017 14:10:58 -0400

Gunnar

And yet you persist.

We have agreed NOT to do preferences between modalities.  Any suggestion that we do so is out of scope for this document.  If you want to write a draft that extends the mechanism, please do and I’ll review it, but PLEASE don’t keep suggesting that we handle preferences between media in this document.  We agreed NOT to do it.

I would prefer the current syntax, and not Accept-Language syntax.

Brian

> On Jun 1, 2017, at 2:01 PM, Gunnar Hellström <[email-masked]> wrote:
> 
>> The group has repeatedly discussed q-values and priority and has always decided to not go down that path.
> I expect our shepherd to lead us to the decision. We had one reviewer requesting us to use the Accept-Language syntax with the q-values.
> 
> I can accept either way, either the one-line syntax used in version -10, or the Accept-Language syntax.
> 
> If we go with the current one-line syntax, I will propose to add the preference between modalities by giving the asterisk a preference interpretation on media level.
> And I will propose to use the -t language subtag for simultaneous languages in other modalities.
> If we go with the Accept-Language syntax, then I will propose to let the q-values have scope over the whole SDP in order to assign preference between modalities,
> and I will propose to let equal q-values or q-values within a narrow interval to indicate a preference for using simultaneous languages in different media. The first item is nice and flexible, the second, for simultaneity may be less elegant.
> 
> I hope you will accept either solution. And do it already in the current draft.
> 
> So we just need the decision on the Accept-Language syntax proposal and then move on.
> 
> Regards
> 
> Gunnar
> 
> 
> 
> 
> 
> 
>> 
>>>> This seems sufficient given our previous conversations. q-values can be applied within further work (although I don't see why ordering doesn't do the job, works in web).
>>>> 
>>> It is not feasible to change syntax by adding q-values in an extension. That will cause interop problems, or complicated needs to negotiate protocol version. So, we need to decide the syntax now and stick closely to it.
>>> 
>>> Ordering is not sufficient because we have a need to set preferences between different media.
>>> And, a minor drawback: ordering does not allow to specify a number of languages in the same media with the same preference. One always will look as if it is more preferred than another. - but I think we can live with that.
>>> 
>>> Maybe the main question is: Will our own one-line syntax really be less complex to parse than the Accept-Language syntax that we might be able to find ready library routines for?
>>> Adam Roach had views on complexity to parse different solutions. Maybe you, Adam can have a view on this?
>>> 
>>> Regards
>>> 
>>> Gunnar
>>> 
>>>> 
>>>> Natasha Rooney | Internet Engineering Director | Internet and Web Team | Technology | GSMA | <mailto:[email-masked]>[email-masked] | +44 (0) 7730 219 765 | @thisNatasha | Skype: <mailto:[email-masked]>[email-masked]
>>>> 
>>>>> On 30 May 2017, at 00:04, Randall Gellens <<mailto:[email-masked]>[email-masked]> wrote:
>>>>> 
> [email-masked] <mailto:[email-masked]>
> +46 708 204 288
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 1 Jun 2017 14:23:47 -0400

On 6/1/17 2:10 PM, Brian Rosen wrote:
> Gunnar
> 
> And yet you persist.
> 
> We have agreed NOT to do preferences between modalities.  Any suggestion 
> that we do so is out of scope for this document.  If you want to write a 
> draft that extends the mechanism, please do and I’ll review it, but 
> PLEASE don’t keep suggesting that we handle preferences between media in 
> this document.  We agreed NOT to do it.
> 

How about enhancing the syntax to support parameters for the values, but 
only as a future extension mechanism? Unknown parameters to be ignored. 
Then at least the hooks will be there to introduce something later if 
desired.

	Thanks,
	Paul

> Brian
> 
>> On Jun 1, 2017, at 2:01 PM, Gunnar Hellström 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> If we go with the Accept-Language syntax, then I will propose to let 
>> the q-values have scope over the whole SDP in order to assign 
>> preference between modalities,
>>>>> Team | Technology | GSMA | 
>>>>> <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> 
>>>>> <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>>>>
>>>>>> <<mailto:[email-masked]>[email-masked] 
>>>>>>> intend to update the draft to collapse the attribute syntax to 
>>>>>>> one line; each attribute can occur at most once per media, with 
>>>>>>> all languages on the same line. This will further reduce the size 
>>>>>>> of the SDP block.
>>>>>>>
>>>>>>> <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>>>>>>
>>>>>> <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>>>>>
>>>>> must take no action based on them, nor must you copy or show them 
>>>>> to anyone; please reply to this email or call +44 207 356 0600 and 
>>>>> highlight the error.
>>>>>
>>>>>
>>>>>
>>>>> <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>>>>
>>>> <mailto:[email-masked]>
>>>> +46 708 204 288
>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 7 Jun 2017 18:20:37 -0400

I posted the message below a week ago but I never saw any responses to it:

> On 6/1/17 2:10 PM, Brian Rosen wrote:

[snip]

> Then at least the hooks will be there to introduce something later if 

I think this would be the wise thing to do in any case. But especially 
so since we have have some issues pending that have been postponed as 
potential future work.

Here is a specific proposal so we have something concrete to discuss:

       hlang-value-list = hlang-value *("," hlang-value)

       hlang-value =  (Language-Tag / asterisk) *(";" hlang-param)

       hlang-param = hlang-param-name ["=" hlang-param-value]

       hlang-param-name = token

       hlang-param-value = token

       Language-Tag = <Defined in BCP 47>

       token = <Defined in RFC4566>

(I am *not* particularly attached to the specifics, but rather just to 
the general notion of having an extensibility hook. If you have issues 
with the syntax details I'm happy to discuss alternatives.)

No specific hlang-params are to be defined in this draft. The semantics 
are that unknown hlang-params are to be ignored, and specific ones can 
be defined in extension drafts.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 7 Jun 2017 15:28:12 -0700

Filed as Ticket #40:  https://trac.ietf.org/trac/slim/ticket/40#ticket

On Wed, Jun 7, 2017 at 3:20 PM, Paul Kyzivat <[email-masked]>
wrote:

> I think this would be the wise thing to do in any case. But especially so
> since we have have some issues pending that have been postponed as
> potential future work.
>
> (I am *not* particularly attached to the specifics, but rather just to the
> general notion of having an extensibility hook. If you have issues with the
> syntax details I'm happy to discuss alternatives.)
>
> are that unknown hlang-params are to be ignored, and specific ones can be
> defined in extension drafts.
>
>         Thanks,
>         Paul
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 7 Jun 2017 17:47:54 -0500

On 6/1/17 9:33 AM, Gunnar Hellström wrote:
> less complex to parse than the Accept-Language syntax that we might be 
> able to find ready library routines for?

As long as it is a space-delimited list of tokens, it should be trivial. 
That's a pretty common SDP pattern.

The prospect of bolting a parser from some other protocol (e.g. 
Accept-Language) onto an SDP parsing library seems like it would be 
quite complex. The libraries I've worked with would almost certainly 
find it easier to write such a parser from scratch.

/a

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 8 Jun 2017 06:54:56 +0200

Den 2017-06-08 kl. 00:47, skrev Adam Roach:
> As long as it is a space-delimited list of tokens, it should be 
> trivial. That's a pretty common SDP pattern.
Thanks for your view on this,
How about the semicolon and comma delimited syntax proposal just 
submitted by Paul? Also trivial?
> find it easier to write such a parser from scratch.
Thanks
Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Fri, 9 Jun 2017 11:59:06 -0700

At 6:20 PM -0400 6/7/17, Paul Kyzivat wrote:

I posted the message below a week ago but
I never saw any responses to it:

On 6/1/17 2:10 PM, Brian Rosen
wrote:

[snip]

I would prefer the current syntax, and
not Accept-Language syntax.

How about enhancing the syntax to support parameters for the values,
but only as a future extension mechanism? Unknown parameters to be
ignored. Then at least the hooks will be there to introduce something
later if desired.

Here is a specific proposal so we have something concrete to
discuss:

hlang-value-list = hlang-value
*("," hlang-value)

hlang-value =  (Language-Tag /
asterisk) *(";" hlang-param)

hlang-param = hlang-param-name
["=" hlang-param-value]

hlang-param-name = token

asterisk    =
"*"   ; an asterisk (ASCII %2A) character

Language-Tag = <Defined in BCP
47>

No specific hlang-params are to be defined in this draft. The
semantics are that unknown hlang-params are to be ignored, and
specific ones can be defined in extension drafts.

I'm not opposed to allowing future extension parameters in the
syntax, but I'm not convinced we need to be so explicit as to their
syntax here (specifying that they consist of a token, an equal sign,
and another token).  I'd be more comfortable saying something
more generic, such as:

hlang-value
=  lang *( "," *" " lang )

lang        =  ( Language-Tag
[extend] ) / asterisk

; Language-Tag defined in
BCP 47

extend      =
";" 1*( %x21-2B / %x2D-3A / %x3C-7E )

; semicolon followed by
printable chars not "," ";" "
"

; ignored in this
document; defined for future extensibility

asterisk    =  "*"   ; an
asterisk (0x2A) character

This permits a semicolon and a series of characters that don't
include comma, semicolon, or space to be appended to a BCP47
Language-Tag.  The specific syntax of such extensions can then be
defined in a future document.

--

Randall Gellens

Opinions are personal;    facts are
suspect;    I speak for myself only

-------------- Randomly selected tag: ---------------

I must have a prodigious quantity of mind; it takes me as much as a

week sometimes to make it up.   --Mark Twain, _The Innocents Abroad_

---

From: Randall Gellens <[email-masked]>
Date: Fri, 9 Jun 2017 12:02:15 -0700

At 5:47 PM -0500 6/7/17, Adam Roach wrote:

>> one-line syntax really be less complex to 
>> parse than the Accept-Language syntax that we 
>> might be able to find ready library routines 
>> for?
>> different solutions. Maybe you, Adam can have 
>> a view on this?
>
>
>  As long as it is a space-delimited list of 
> tokens, it should be trivial. That's a pretty 
> common SDP pattern.

That's what's in the draft now (based on your earlier suggestion).

Paul has proposed a syntax using semicolons 
instead of spaces.  If that will make the parsing 
even slightly more complicated, I'd be inclined 
to stick with the simple space-delimited list we 
have now, and if we find that we do need to add 
parameters, we introduce new attributes at that 
time.

>  The prospect of bolting a parser from some 
> other protocol (e.g. Accept-Language) onto an 
> SDP parsing library seems like it would be 
> quite complex. The libraries I've worked with 
> would almost certainly find it easier to write 
> such a parser from scratch.
>
>  /a
>

-------------- Randomly selected tag: ---------------
Nothing is illegal if one hundred businessmen decide to do it.
        --Andrew Young

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 9 Jun 2017 15:40:17 -0400

On 6/9/17 2:59 PM, Randall Gellens wrote:
> I'm not opposed to allowing future extension parameters in the syntax, 
> but I'm not convinced we need to be so explicit as to their syntax here 
> (specifying that they consist of a token, an equal sign, and another 
> token).  I'd be more comfortable saying something more generic, such as:
> 
>        hlang-value =  lang *( "," *" " lang )
> lang        =  ( Language-Tag [extend] ) / asterisk
>         ; Language-Tag defined in BCP 47
>        extend      = ";" 1*( %x21-2B / %x2D-3A / %x3C-7E )
>         ; semicolon followed by printable chars not "," ";" " "
>         ; ignored in this document; defined for future extensibility
> asterisk    =  "*"   ; an asterisk (0x2A) character
> 
> This permits a semicolon and a series of characters that don't include 
> comma, semicolon, or space to be appended to a BCP47 Language-Tag.  The 
> specific syntax of such extensions can then be defined in a future document.

I don't quite follow the details above. But I am not opposed to using a 
more generic format as a placeholder for future parameters.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Fri, 9 Jun 2017 14:47:56 -0700

At 3:40 PM -0400 6/9/17, Paul Kyzivat wrote:

>>>>  How about enhancing the syntax to support parameters for the 
>>>> values, but only as a future extension mechanism? Unknown 
>>>> parameters to be ignored. Then at least the hooks will be there 
>>>> to introduce something later if desired.
>>>
>>>  I think this would be the wise thing to do in any case. But 
>>> especially so since we have have some issues pending that have 
>>> been postponed as potential future work.
>>>
>>>  (I am *not* particularly attached to the specifics, but rather 
>>> just to the general notion of having an extensibility hook. If 
>>> you have issues with the syntax details I'm happy to discuss 
>>> alternatives.)
>>>
>> syntax, but I'm not convinced we need to be so explicit as to 
>> their syntax here (specifying that they consist of a token, an 
>> equal sign, and another token).  I'd be more comfortable saying 
>> something more generic, such as:
>>
>  I don't quite follow the details above.

It says:

	(1) The attribute value is an "hlang-value" followed by zero or 
more sets of comma, optional spaces, and another "hlang-value"

	(2) An "hlang-value" is a BCP 47 Language-Tag optionally followed 
by an "extend", or an asterisk

	(3) An "extend" is a semicolon followed by one or more printable 
characters other than comma, semicolon and space

>   But I am not opposed to using a more generic format as a 
> placeholder for future parameters.
>
>  	Thanks,
>  	Paul

-------------- Randomly selected tag: ---------------
komorebi (n, Japanese): the scene produced by interplay of sunlight
and trees