Re: [MMUSIC] Trafficclass Attribute -02 submitted

"Paul E. Jones" <> Thu, 23 August 2012 20:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4A6221F8458 for <>; Thu, 23 Aug 2012 13:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=-0.506, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_28=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z2L-+mUYx6b3 for <>; Thu, 23 Aug 2012 13:28:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9CFAD21F8450 for <>; Thu, 23 Aug 2012 13:28:53 -0700 (PDT)
Received: from sydney ( []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id q7NKSpBp024953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Aug 2012 16:28:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=dublin; t=1345753732; bh=jxhCM/l33IKBU2PnQkJAfJunPWW8dv0r81w0BerShVk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZbSDY0bC7GHUVarapfKIquJ9OxMiv6m3e1XI1HizpWW/Xe2nVjWGz2LmjjJXuoCHx 5tl4SrEYAUAdKQ+OTuhdq3RJLHVyShhegamykawnyXKvBhox1xpGMw6b0J3WFxpauy 0B24b+ivB/Gef1B6YGQQaL4FBkgcpjE91pClinx8=
From: "Paul E. Jones" <>
To: 'Paul Kyzivat' <>
References: <> <> <002f01cd80b2$24455530$6ccfff90$> <>
In-Reply-To: <>
Date: Thu, 23 Aug 2012 16:29:00 -0400
Message-ID: <016001cd816d$ee4e0000$caea0000$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIkCjpD5G0c/4AfIxmKojzRm/pGSwKLFVLyAZ6pDFwCFSCbGJaIyWCg
Content-Language: en-us
Subject: Re: [MMUSIC] Trafficclass Attribute -02 submitted
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Aug 2012 20:28:54 -0000


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