Blair Whitney (whitney@connectedsystems.com)
Thu, 5 Aug 1999 11:15:39 -0700
For what it is worth, we have a product that uses IMA ADPCM at 32kbps.
I realize that this codec will not be part of the VPIM spec,
but it may be nice to allow the proposed MIME tag values to allow this
codec.
This codec usage would be confused with G.726 possibly in:
>3.5 MIME audio content-types
>
> Feature tag name Legal values
> ---------------- ------------
> mime-audio audio/32kadpcm
Although it could be resolved with:
>3.1 Voice codec
>
> Feature tag name Legal values
> ---------------- ------------
> codec G-726-32
IMA-32 ???
-----Original Message-----
From: Graham Klyne [mailto:GK@Dial.pipex.com]
Sent: Thursday, August 05, 1999 10:27 AM
To: Laile Di Silvestro (Exchange)
Cc: VPIM discussion list; vpim@lists.neystadt.org
Subject: RE: [VPIM] draft-ema-vpim-wav-00.txt
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)
Copyright (c) 1999. Electronic Messaging Association, Inc. All rights reserved. A member service of EMA-The Electronic Business Forum 1655 North Fort Myer Drive, Suite 500, Arlington, Virginia 22209-3108 el. 703-524-5550 Fax 703-524-5558 E-Mail: support@ema.org
This archive was generated by hypermail 2.0b3 on Tue Mar 19 2002 - 01:04:16 IDT