Re: [MMUSIC] Trafficclass Attribute -02 submitted

Some comments on the new version:

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)

But it would be more readable as:

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

(Those symbols are defined with ABNF in RFC 5234. If so you need a 
reference. Paraphrasing 3261, you might say: "Appendix B.1 of RFC 5234 
defines a set of core rules that are used by this specification, and not 
repeated here.")

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

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

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.

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

	Thanks,
	Paul

On 7/17/12 3:19 PM, James Polk wrote:
> MMUSIC
>
> We've submitted a revision of the Traffic Class Label attribute here
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-traffic-class-for-sdp
>
> These are the following changes made between the WG -01 version and
> the -02 version:
>
> - converged the use of terms 'parent' and 'category' to just
> 'category' for consistency.
>
> - changed ABNF to reflect extensibility by not having applications
> and adjectives named in the ABNF, rather have them merely IANA
> registered. This was brought up on the list and in the Paris
> meeting.
>
> - merged the qualified and unqualified adjective sections into a
> single section on adjectives, but allowing some to have a
> preceding qualifier. This was brought up on the list and in the
> Paris meeting.
>
> - text clean-up
>
> We have one known open issue, which is related to some document
> structure around the categories, applications and adjectives.
>
> We have another known open issue regarding articulating better which
> adjectives are appropriate with which applications, as well as which
> applications are appropriate with which categories.
>
> Other comments and questions are solicited.
>
> James/Subha/Paul
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>