Re: [MMUSIC] Trafficclass Attribute -02 submitted

["Paul E. Jones" <[e-mail]>]

Paul,

My apologies for the belated reply.  I hope this is still of value.

> In section 3 (SDP syntax):
> 
>     tcl-token = %2D / %30-%39 / %41-%5A / %61-7A
> 
> That only allows one character tokens. Minimally you probably want:
> 
>     tcl-token = 1*(%2D / %30-%39 / %41-%5A / %61-7A)

Ooops... agreed.  This is what was intended.
 
> But it would be more readable as:
> 
>     tcl-token = 1*( ALPHA / DIGIT / "-" )

This is OK, but we also need to include the underscore character.  So, we
need this:

     tcl-token = 1*( ALPHA / DIGIT / "-" / "_" )

For some reason, that was left out.
 
> But that allows leading and trailing, and multiple consecutive "-"s. So
> you could tighten it up with:
> 
>     tcl-token = ALPHA 0*(ALPHA / DIGIT) 0*("-" 1*(ALPHA / DIGIT))

We want to allow a leading underscore.  So, perhaps this:

  tcl-token = (ALPHA / "_") 0*(ALPHA / DIGIT) 0*(("-" / "_") 1*(ALPHA /
DIGIT))

This prevents "apple-_pie", though. Do we want to allow more than one
non-alpha-numeric to be together? I'd be content to disallow it, since the
purpose for - or _ is for readability and putting them together makes it
less readable, IMO.
 
> Also, your syntax doesn't cover non-standard-adjectives. You could cover
> that by:
> 
>     adjective = standard-adjective / non-standard-adjective
> 
>     standard-adjective = classified-adjective / unclassified-adjective
> 
>     non-standard-adjective = "_" standard-adjective

I don't think we should separate standard and non-standard adjectives via
syntax.  If we have a particular interpretation of "_foo" to mean that it is
non-standard, I think the above syntax will work.  We just need to explain
that adjectives with leading underscores are for non-standard use.
 
> Sections 6.3 & 6.4:
> 
> "Specification Required" implies expert review. That in turn calls for
> some criteria by which the expert can decide if a proposed value is
> appropriate to be registered.

What we wanted was that IETF-agreed adjectives would be supported with some
documentation (i.e., an RFC).  However, if folks prefer to allow anyone to
register an adjective for whatever purpose, we could drop the requirement.
What should be used here?

 
> IIUC, 'aq', 'admitted', 'non-admitted', and 'none' are *not* Unqualified
> adjectives.  Rather,
> 
> 'aq:admitted', 'aq:non-admitted', and 'aq:none' are *qualified*
> adjectives.
> 	
> Does the distinction matter for registration? Should there be different
> criteria for registering new qualified adjectives? Maybe so. Maybe there
> should be some review of whether the new 'aq:foo' is compatible with the
> intended meaning of 'aq'???

"aq" by itself is not an adjective.  "aq:admitted" is an adjective.

Consider draft-jennings-rtcweb-qos-00.  In there, we mention there that a
media flow can be designated as low, medium, or high importance. Not to
cause a war of names, but let's those priority values.

So for WebRTC, we might define:
  pri:low
  pri:medium
  pri:high

So, an audio flow might be labeled:
  conversational.audio.pri:medium.aq:non-admitted

The "aq:" and "pri:" part of the adjective is something I would like to
allow developers to search for.  Perhaps one day we introduce
"pri:very-high".  A device may not know what "very-high" means, but it can
match the substring "pri:" and at least recognize the adjective as being a
priority adjective.

At least that was the intent.

What I would like to do is have a multi-level registration akin to what we
have for media types.  So, we would have something like this:

+----------------------+----------------------+----------------------+
| Category             | Application          | Adjective            |
+----------------------+----------------------+----------------------+
| conversational       | audio                | immersive            |
|                      |                      | aq:                  |
|                      |                      |    admitted          |
|                      |                      |    non-admitted      |
|                      |                      |                      |
|                      |                      | avconf               |
|                      |                      |                      |
|                      | video                | immersive            |
|                      |                      | aq:                  |
|                      |                      |    admitted          |
|                      |                      |    non-admitted      |
|                      |                      |    partial           |
|                      |                      | avconf               |
|                      |                      |                      |
|                      | text                 | realtime-text        |
+----------------------+----------------------+----------------------+
| multimedia-confer... | app-sharing          |                      |
|                      |                      |                      |
|                      | whiteboarding        |                      |
+----------------------+----------------------+----------------------+
| broadcast            | audio                |                      |
|                      |                      |                      |
|                      | video                |                      |
+----------------------+----------------------+----------------------+
...

I'm not precisely sure what the best way is to represent "aq:", but I do not
think we want to introduce another level in the hierarchy.  It's just a
prefix to a family of related adjectives.

Paul