Graham Klyne (GK@dial.pipex.com)
Thu, 05 Aug 1999 18:26:48 +0100
At 06:33 05/08/99 -0700, Laile Di Silvestro (Exchange) wrote:
>Graham, a while back did you define feature expressions for an audio
>content-features profile that included codec?
Glen Parsons made a proposal, to which I made some small comments...
#g
--For information, from the recesses of my e-mail archives...
Glen's proposal: >3. VPIM feature tags > > This section enumerates and briefly describes a number of feature > tags that are defined for use with the Voice Profile for Internet > Mail version 3 (VPIM v3) for voice messaging > systems and applications. These tags may be used also by other > systems and applications that support corresponding capabilities. > > The feature tags presented below are those that a VPIM v3 system is > expected to recognize its ability or non-ability to handle. The > values are listed with the default first. > > NOTE: The presence of a feature tag in this list does > not mean that a VPIM v3 system must have that capability; > rather, it must recognize the feature tag and deal with > it according to the capabilities that it does have. > Further, a VPIM v3 system is not prevented from > recognizing and offering additional feature tags. The > list below is intended to provide a minimum vocabulary > that all VPIM v3 systems can use in a consistent fashion. > > If an unrecognized or unused feature tag is received, the > feature set matching rule (described in [SYNTAX]) operates > so that tag is effectively ignored. > >3.1 Voice codec > > Feature tag name Legal values > ---------------- ------------ > codec G.726-32 > G.711-mu > G.711-a > G.729a > G.723.1 > GSM-6.10 > ...any more? > >3.2 Voice headers > > Feature tag name Legal values > ---------------- ------------ > codec-header None > WAV > AIFF > ASF > RA > ...more? > >3.3 UA Terminal type > > Feature tag name Legal values > ---------------- ------------ > ua-terminal fixed-handset > desktop > UM-desktop > modile-handset > Pager > ...more? > >3.4 Audio Channels > > Feature tag name Legal values > ---------------- ------------ > channels Mono > Stereo > ...more? > > >3.5 MIME audio content-types > > Feature tag name Legal values > ---------------- ------------ > mime-audio audio/32kadpcm > audio/wav > audio/basic > audio/gsm > audio/* > ..more?
My comments: >>3.1 Voice codec [...] >Given that the IETF feature tag namespace (used here) can potentially cover >a very wide range of different applications, would it be helpful to use the >tag name 'audio-codec' here? > >Also, I note that the conneg syntax does not permit "." in token values, as >used above. (To allow this would introduce an ambiguity into the >grammar.) The allowed characters in a token are 'token = ALPHA *( ALPHA / >DIGIT / "-" )'. > >I offer two alternative solutions: >(a) use string values rather than tokens (i.e. the codec identifying tokens >ae enclosed in quites, as "G.726-32", etc.). >(b) delete periods in the token names, or replace them with '-' (e.g. >"G726-32" or "G-726-32"). > >FWIW, faced with similar choices in the fax work, we simply removed the >period; e.g. we have a token value defined by reference to T.85: > image-coding-constraint=JBIG-T85
>>3.2 Voice headers [...] > >In the fax work, we used a tag to describe a "file structure" rather than a >"header format", so we have the tag: > > image-file-structure=TIFF-S > etc. > >Would this be a more flexible approach than just defining a header format? >(I am assuming that a header format is an implicit part of a file structure.)
>>3.3 UA Terminal type [...] > >A tag called 'ua-terminal' could have wider applicability than just audio >devices.
>>3.4 Audio Channels [...] > >Use tag name 'audio-channels'? > >What is the range of possible values here? Is it simply a number (i.e. >n-channels), or is there a desire to capture other related information >(e.g. surround-sound)? > >Not being an audio expert, the former seems more appropriate in which case >I'd suggest making the feature value numeric (so I can send you my 8-track >home recording?).
>>3.5 MIME audio content-types [...] > >Here, you touch on an interesting issue that the conneg haven't fully >resolved yet, though it has been discussed. One obvious capability of any >recipient is the MIME types that it can accept. If we have a generic way >to indicate MIME type handling capability then I don't think this tag would >be needed.
Since I made that response, an additional proposal has been published for review: <draft-ietf-conneg-feature-type-01.txt>.
This defines a feature tag 'type' that can be used to indicate a MIME content-type value. This is a "generic way to indicate MIME type handling capability" alluded to in that earlier comment.
------------ Graham Klyne (GK@ACM.ORG)
This archive was generated by hypermail 2.0b3 on Tue Mar 19 2002 - 01:04:16 IDT