Re: [Slim] draft-ietf-slim-negotiating-human-language-10: extensibility

[Paul Kyzivat <[e-mail]>]

On 6/9/17 2:59 PM, Randall Gellens wrote:
> 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:23 PM, Paul Kyzivat wrote:
>>> 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.
>>
>> 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
>>
>>       asterisk    = "*"   ; an asterisk (ASCII %2A) character
>>
>>       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.
> 
> 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