Subject: Re: [MMUSIC] Trafficclass Attribute -02 submitted

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 22 Aug 2012 18:04:45 -0400

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Aug 2012 19:41:17 -0400

> For some reason, that was left out.

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

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

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

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

> purpose for - or _ is for readability and putting them together makes it

AMEN!

> that adjectives with leading underscores are for non-standard use.

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

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

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

> have for media types.  So, we would have something like this:

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 23 Aug 2012 16:29:00 -0400

Paul,

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

This is understandable, and it's also the subject of RFC 6648.  While I
might get shot for saying so, I actually do prefer having some means of
indicating that a value is non-standard.  At least then people can know to
ignore it. My personal opinion is that allowing "_foo" means that people are
creating their own risk.  That's fine.  Disallowing "_foo" means people will
use "foo" and then one day when the IETF standardizing "foo" we have two
values with perhaps very different meanings.
 
> Do you want "foo:_bar" to be a valid adjective? How about "_foo:bar"?

An "adjective" is the who string in each example, so both should be legal.

> Then define the adjectives to allow the leading underscore where you want
> it.

The reason I want to allow "foo:_bar" is for the same reasons we allow
"_foo" or other vendor-specific value.  If we define a class of adjectives
(e.g, "aq:" or "pri:"), some vendor might have a value that fits within that
class.  So, they use "aq:_foo".  I don't think it's a bad idea at all.  As I
mentioned before, the adjective is the whole string, so it is either known
or not as a unit.  If someone cares to see that this is an adjective in a
known class, they can match on "aq:".  The "_foo" part is just treated as an
unknown value.
 
> non-standard-adjective = "_" standard-adjective

Introducing "tcl-sep" might be reasonable, but I think we're making this
unnecessarily complex introducing "std-adj..." and "non-standard-adj..."
productions.  What benefit do we get from that?  I would prefer the "_"
(when it is leading) to be understood as non-standard, but I don't really
want to create parallel syntax.
 
> >> Also, your syntax doesn't cover non-standard-adjectives. You could
> >> cover that by:
> >>
> > 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.
> 

If we really want to separate out standard and non-standard adjectives with
separate syntax, yes, I think you accomplished that (modulo the fact one
cannot have "aq:_foo").

> >> IIUC, 'aq', 'admitted', 'non-admitted', and 'none' are *not*
> >> Unqualified adjectives.  Rather,
> >>
> >> 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'???
> >

We could do that, but is there benefit in doing so?  It would potentially
mean a 4-level registration (category, application, adjective-prefix,
adjective suffix).  I really have no idea what people would prefer there.  I
have no preference.  I just don't want to make it complicated.

> > 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:
> >
\
...
/
> qualified will sort together.

That's what I was hoping to do by just having three levels.  I displayed the
"aq:" separately, but what I would expect to see on the web page would be
just the sorted list, as you said.

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

Yeah, agreed.
 
> has no grounds other than his own opinion to reject the request.)

Understood.

Paul