Subject: Re: [MMUSIC] draft-ietf-mmusic-traffic-class-for-sdp-01

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Mar 2012 12:56:18 +0200

James,

We've had other discussions on "immersive". This is other stuff I had 
that didn't seem worth bringing up in the meeting:

In section 3, the way qualified-adjective is defined, the values for 
q-adjective ("admitted", ...) can be used not only with "aq" (e.g. 
aq:admitted), but can also be used with any other extension-mech that 
might later be defined.

That is ok if it is your intent. Is it?

I'm not at all clear what the distinction is between qualifed and 
unqualified adjectives. I suspect you could get the effect you want by 
discarding the distinction between qualified and unqualified adjectives, 
and simply defining "aq-admitted", "aq-non-admitted", and "aq-none" as 
adjectives.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 27 Mar 2012 12:55:12 -0400

Paul,

The previous draft had it that way (somewhat).  We had "admitted" and
"non-admitted" at the end.  However, it was suggested that we group related
things together.  So, for indicating "admitted" or "non-admitted" or "none",
we defined the "admission qualifier" (aq).  There may be other adjective
groups that we might define in the future (or now if people can think of
useful examples).

As one perhaps less useful example might be to indicate the resolution of a
video.  So, there might be a "res:1080|720|360" or "res:high|medium|low".

One benefit in defining groups of adjectives is that if you are looking for
the admission qualifier value, for example, then you can find the
"aq:<whatever>" adjective.  You may not know what "<whatever>" means, but at
least you can identify that it is the admission qualifier value.

So, it's there just to provide a grouping construct and to allow for
identification of the group, even if the value in the group is not
recognized.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Monday, March 26, 2012 6:56 AM
> To: IETF MMUSIC WG
> Subject: Re: [MMUSIC] draft-ietf-mmusic-traffic-class-for-sdp-01
> 
> James,
> 
> We've had other discussions on "immersive". This is other stuff I had that
> didn't seem worth bringing up in the meeting:
> 
> In section 3, the way qualified-adjective is defined, the values for q-
> adjective ("admitted", ...) can be used not only with "aq" (e.g.
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Mar 2012 19:13:30 +0200

On 3/27/12 6:55 PM, Paul E. Jones wrote:
> "aq:<whatever>" adjective.  You may not know what"<whatever>" means, but at

I see the value in the grouping. I just don't see the value in 
introducing formal syntax for that grouping. I think it would make the 
parser simpler to achieve the sort of grouping you are talking about 
through an informal naming convention on the attributes. You could have 
exactly the same names you do now if you simply permitted ":" as a valid 
character anywhere in attribute names. Or, you can simply settle for 
some other separator character in the convention, like "-", as in 
"aq-accepted".

The special syntax for qualified attributes leaves me expecting more - 
some special significance to qualifiers in general and the aq qualifier.

	Thanks,
	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 28 Mar 2012 02:55:29 -0500

Paul

in-line

At 05:56 AM 3/26/2012, Paul Kyzivat wrote:
>James,
>
>We've had other discussions on "immersive".

Yes we have, however, that indication we still have use for, so it'll 
need to be replaced with something unique that can mean what we 
intent here for "immersive". Any suggestions?

>This is other stuff I had that didn't seem worth bringing up in the meeting:
>
>aq:admitted), but can also be used with any other extension-mech 
>that might later be defined.
>

The "qualified" aspect of the adjectives came from the idea of 
reducing the cac-class component back into being an adjective, which 
is exactly what it is. That's #1. #2 was that we believe we have use 
for a admission adjective maining "none", defined that CAC wasn't 
attempted for this traffic flow. Now, just having a generic adjective 
"none" begs the question "none what"? If we qualified what the "none" 
applied to (i.e., about admission specifically), the "none" is given 
context that can be used. There may be a different reasons to have 
some other traffic class have an adjective of "none", but a different context.

That's where this all came from.

Now, that said, what you have below is interesting (i.e., 
"...defining "aq-admitted", "aq-non-admitted", and "aq-none" as adjectives...")

James

>unqualified adjectives. I suspect you could get the effect you want 
>by discarding the distinction between qualified and unqualified 
>adjectives, and simply defining "aq-admitted", "aq-non-admitted", 
>and "aq-none" as adjectives.
>
>         Thanks,
>         Paul

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 28 Mar 2012 02:58:49 -0500

>video.  So, there might be a "res:1080|720|360" or "res:high|medium|low".

to further beat this horse (made along the previous note) is this, 
just having a adjective as "low" doesn't mean much to anyone, and is 
limiting future traffic classes to not being able to use "low" with a 
different meaning. "res:low" (or your suggestion of a "res-low") 
gives context to the adjective.

James

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 28 Mar 2012 03:00:39 -0500

At 12:13 PM 3/27/2012, Paul Kyzivat wrote:
>introducing formal syntax for that grouping. I think it would make 
>the parser simpler to achieve the sort of grouping you are talking 
>about through an informal naming convention on the attributes. You 
>could have exactly the same names you do now if you simply permitted 
>":" as a valid character anywhere in attribute names. Or, you can 
>simply settle for some other separator character in the convention, 
>like "-", as in "aq-accepted".
>
>The special syntax for qualified attributes leaves me expecting more 
>- some special significance to qualifiers in general and the aq qualifier.

Like I said, this is a good suggestion you have here.

James