Re: [MMUSIC] Trafficclass Attribute -02 submitted

[Paul Kyzivat <[e-mail]>]

On 8/22/12 6:04 PM, Paul E. Jones wrote:
> 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.

That answers my comment: your syntax doesn't cover non-standard-adjectives

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

Well, there are two things to deal with:
- what forms are allowed
- how to represent that in ABNF

Well formed ABNF can answer both questions, as long as it isn't so 
obscure that people don't understand it.

I'm not in love with the leading "_" to signal non-standard adjectives, 
but neither do I hate it. But I'm much less fond of sequences of _ and -.

Do you want "foo:_bar" to be a valid adjective? How about "_foo:bar"?
ISTM that foo:_bar is probably a bad idea. So I'm thinking it would be 
better to define tcl_token so it doesn't permit a leading underscore. 
Then define the adjectives to allow the leading underscore where you 
want it.

So perhaps:

tcl-sep = "-" / "_"

tcl_token = ALPHA 0*(ALPHA / DIGIT) 0*((tcl-sep 1*(ALPHA / DIGIT))

std-unclassified-adj = tcl-token

std-adj-classifier = std-unclassified-adj ":"

adj-qualifier = tcl-token

std-classified_adj = std-adj-classifier adj-qualifier

standard-adjective = std-unclassified-adj / std-classified-adj

non-standard-adjective = "_" standard-adjective

I find this more readable, and it provides terms to talk about in the text.


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

AMEN!

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

Hopefully I made a case above for putting it into the syntax.

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

I'm not an expert at this. Look at RFC 5226 and pick the policy you want.

Regardless of which policy, the doc should specify *some* criteria for 
distinguishing an acceptable new value from an unacceptable one. If 
there is a policy that requires an expert review (like the Expert Review 
policy you currently call for) it's more important to make the criteria 
explicit.

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

I see nothing to prevent both "aq" and "aq:admitted" from being 
registered. If you don't want to permit that, then say so.

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

The structure of the registry can be settled later. Work out the desired 
usage first. (But to get all that into IANA will be difficult.)

My first thought is that IANA can simply register standard-adjectives 
without regard for whether they are qualified or not. The ones that are 
qualified will sort together.

But you might want a higher bar for registering a new adj-qualifier for 
an existing std-adj-classifier than you do for registering a new 
std-unclassified-adj. That will require more complex rules, and *might* 
require a different table structure.

E.g.

suppose aq:admitted and aq:non-admitted have already been registered.

Would you want it to be ok to register aq:foo for some purpose unrelated 
to the other two? I think not. What guidelines would you want to give to 
an expert to ensure that doesn't happen?

(If there are no guidelines, and someone attempts to do this, the expert 
has no grounds other than his own opinion to reject the request.)

	Thanks,
	Paul K