Re: [MMUSIC] Trafficclass Attribute -02 submitted

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

Paul,

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

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.

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

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

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

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

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:
> >
> > +----------------------+----------------------+----------------------+
> > | Category             | Application          | Adjective            |
> > +----------------------+----------------------+----------------------+
> > | conversational       | audio                | immersive            |
\
...
/
> 
> 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.

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

Yeah, agreed.
 
> (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.)

Understood.

Paul