Subject: [Slim] #40 Syntax Extensibility

From: Natasha Rooney <[email-masked]>
Date: Thu, 8 Jun 2017 17:27:11 +0000

Hi all,

https://trac.ietf.org/trac/slim/ticket/40

Ticket #40 discusses enhancing the syntax for the benefit of extensibility. Please review this and respond (author and all WG attendees). Please see the original text from Paul Kyzivat:

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

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.

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]>

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: Randall Gellens <[email-masked]>
Date: Fri, 9 Jun 2017 14:54:41 -0700

At 5:27 PM +0000 6/8/17, Natasha Rooney wrote:

>  Hi all,
>
> 
> <https://trac.ietf.org/trac/slim/ticket/40>https://trac.ietf.org/trac/slim/ticket/40
>
>  Ticket #40 discusses enhancing the syntax for the benefit of 
> extensibility. Please review this and respond (author and all WG 
> attendees). Please see the original text from Paul Kyzivat:

I proposed a more general version of the ABNF earlier today; however, 
Adam's comment that a space-delimited list of values is the easiest 
to parse and most consistent with other SDP attributes makes me 
reluctant to switch to a more complex syntax absent assurances that 
it wouldn't add extra complexity.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
There is not much to say about most airplane journeys. Anything
remarkable must be disastrous, so you define a good flight by
negatives: you didn't get hijacked, you didn't crash, you didn't
throw up, you weren't late, you weren't nauseated by the food.
So you're grateful.
        --Paul Theroux, The Old Patagonian Express, 1979

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 12 Jun 2017 15:38:42 +0200

Den 2017-06-09 kl. 23:54, skrev Randall Gellens:
> Adam's comment that a space-delimited list of values is the easiest to 
> parse and most consistent with other SDP attributes makes me reluctant 
> to switch to a more complex syntax absent assurances that it wouldn't 
> add extra complexity.
>
We also do not know that it is exactly new parameters on the language 
tags that will be the desired extensions.
It could just as well be alternatives to the asterisk, valid for the 
whole media description. Or other features.

My efforts to make a requirements overview show some features that could 
be solved by new language tag parameters:
1) in 3.10.2 :    P.  Information to offering party about both common 
capabilities and
    selected languages in negotiation result

2) In 3.8.5:    P.  Coarse preference Hi/Lo per language and direction 
in different
    modalities

3) In 3.5  X. Combination of simultaneous languages in different media 
and same
    direction.

I hope that 2 and 3 can be solved either by the current ideas of using 
the asterisk and the "t" extension, or the new SDP grouping semantics.

That would leave us with item 1 as a feature that could use new language 
tag parameters. Is it worth the efforts? Do others see other extension 
needs than the ones identified through my Requirements collection under 
subject "[Slim] Requirements for the real-time case!.

/Gunnar

Gunnar

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