CAP v1.1 IPAWS Profile

[Tom Wood <wood@xmission.com>]

To the OASIS committee,

   I have been reviewing the Jan 20 spreadsheet from Elysa Jones
proposing element requirements for the IPAWS CAP 1.1 Profile.
This is specifically sheet one of the document:
http://www.oasis-open.org/committees/download.php/30877/CAP-IPAWS-Public-Review-Profile-Spreadsheet.xls
CAP v1.1 IPAWS Public Review Profile Specification

Over that past week I have been working on implementing code to
support the current draft CAP-EAS profile defined by the CAP EAS Industry group.
I am presently in the middle of attempting to support audio as described in the
CAP <resource> blocks. My experience has brought to light some important
difficulties with the profile.

I have some specific and intertwined comments and observations in regard to both the
CAP-EAS profile and the OASIS profile specification proposed for elements
of the <resource> blocks.
Specifically these reference the elements <resourceDesc> and <mimeType> and <uri>.

CAP EAS audio requirements.
The CAP EAS profile defines two audio formats (WAV and MPEG3) files for audio and two data
transfer mechanisms (file and stream). In the future it is possible that this could expand.
Audio information is especially necessary for creating basic EAS from a CAP
description. EAS defines an audio voice message as a part of the EAS audio
format. Without this basic element, one must generate audio using Text to Speech
methods. The streaming audio option is a requirement in the spec due to the the
nature of the national EAS alerts (EAN and EAT). These alerts provide live
voice audio, presumably from the president or an authorized White House spokeperson.
WAV or MPEG files are defined in the spec because the standard day to day EAS never
uses live voice audio, but typically provide audio.

Programming disambiguation requirements.

It is essential that the elements of a CAP resource block (and there
can be more than one) can be parsed to exactly determine
the type of audio referenced as a CAP resource.
Given the different options described above, it must be clear
how to handle audio as encountered inside a CAP interpreter.
Given the elements <resourceDesc>, <mimeType>, and <uri> 
this determination can be achieved in up to three ways.

1. <resourceDesc> 
 According the the CAP 1.1 specification, this required field must be comprised of:

The text describing the type and content of the resource file.
Another comment states:
The human-readable text describing the content and kind, such as 
map  or  photo,  of the resource file.

The EAS-CAP Industry group profile defined two labels:
 A. EAS Audio
 B. EAS Streaming Audio

The OASIS profile has suggested that this label be reduced to the
generic "EAS Broadcast Content".

The EAS-CAP Industry group profile is immediately preferable for implementation as
it achieves two levels of disambiguation.
  I.  It limits the resource to EAS content.
  II. It can be used to tell determine file audio vs streaming audio.

The proposed OASIS profile only achieves one of these objectives, it can be
used to determine EAS content. But it cannot be used to determine audio or video or still
images or text, etc. I believe that the CAP 1.1 spec is meant to be interpreted
non-generically, and thus describe the type and content of the resource file.

Therefore, I believe that OASIS should return back to the proposed labels
from the EAS-CAP Industry group.

Note that the EAS-CAP Industry group profile labels still do not determine
audio format (WAV or MPEG). Using the profile,
this can only be determined by adding an appropriate <mimeType>.

An alternative would be to define the <resourceDesc> more specifically,
so that it included file format in the label (EG EAS WAV Audio or EAS MPEG Audio).
This seems to me to be a slippery slope towards a difficult or cumbersome syntax.
Also, MIME types exist partly to solve this very problem.

2. <mimeType>
 According the the CAP 1.1 specification, this optional element must follow RFC 2046.
A <mimeType> is typically of the form type/subtype. EG audio/basic or audio/x-wav or audio/mpeg
The EAS-CAP Industry group profile did not define any of the mimeTypes.
The OASIS profile describes the type of data accepted for audio, but does not
define any mimeTypes.

In my opinion, the lack of definition of mimeTypes in the EAS-CAP profile is
a significant oversight.

In theory, this field can provide the exact determination for the audio resource data,
however, there has to be exact, acceptable and standard definitions for this field.
That presents something of a problem. If you look at the <mimeTypes> described at
http://www.iana.org/assignments/media-types/audio/
there is not even mention of audio/x-wav, which is widely used elsewhere for
WAV files. There is also ambiguity with the same <mimeType> being used
for both streaming and file content (eg audio/mpeg).
Furthermore, CAP 1.1 describes this as an optional field, whereas the
<resourceDesc> is a required element.

This presents a real problem that is thus not solved by either current
draft EAS-CAP Industry group spec or the OASIS spec. Presently,
one cannot determine the basic audio format WAV vs MPEG unless
one defines a <mimeType> for these resources. This would also make the
<mimeType> one of those elements that is optional in CAP in general, but must
be required in the EA -CAP profile. Note that the draft EAS-CAP profile missed this
point and labeled the <mimeType> element optional. Also, one cannot
rely on the <mimeType> to determine if the audio is in a stream or is just a file.

3. <uri>  -
  This field provides the location of the resource.
In this case, it would be a file or stream name of audio.
Eg http://mywebsite.net/audiofile.wav or http://mywebsite.net/audiofile.mp3 or
http://mywebsite.net:8000/audiofile.mp3 or even
on the local server as /tmp/audiofile.wav.

 The EAS-CAP Industry group profile simply defines the use of this field. It is obviously
required to actually retrieve a file or to connect to a stream.

 The OASIS profile makes no mention of <uri>. I assume this is due to this
field being well understood and cleanly defined.

One could use the file name extension of the <uri> value to determine audio format.
However, this is not really a good idea as file extensions are largely an informal
convention and not even required. Also, this cannot be used to distinguish a file from a stream.
So again, the programming requirements cannot be met by using file extensions
parsed from the <uri> value.

The only other option I can think of for determining file format is to actually
download the data for one of these resources and examines it internally
for a magic number or format info. But this is very inefficient, as one then is required
to download a potentially large amount of data to make a basic determination.

Final Points and Conclusion

Requirement: Definitions must be improved in the current draft proposals to allow
audio support to actually and consistently be implemented.

With both the draft EAS-CAP profile and the OASIS profile,
the <resourceDesc> can be used to determine at least which resource
blocks are of interest for EAS use.
I  think that something more descriptive is needed and is useful beyond the
OASIS proposed label of "EAS Broadcast Content".

 It is my opinion that the value of this element should describe
more than just EAS content. I think it should be used to
distinguish EAS audio since audio is a fundamental part of EAS,
whereas other media types, such as video and images, are not.
 These other types can augment EAS in broadcast media, so I am not
at all opposed to <resourceDesc> values that include defined values
for video and image, etc.
 Furthermore, due to the potential difficulties of unambiguous <mimetypes>
for streaming content, I think <resourceDesc> should be used as the
EAS-CAP profile has defined it to specifically label streaming audio as opposed to file audio.
Finally, more descriptive labels would be in line with the definition given in the CAP spec.

 Also importantly, I think that <mimeType> must become a required and
well defined set of values for CAP to EAS. If this is can be completely defined, the final definition for
<resourceDesc> will not matter. But if sttreaming cannot be defined unambiguously
through the <mimeType>, then both <resourceDesc> and <mimeType> are needed.

I have found the following mime types for use with audio resources.
  WAV files                  : audio/x-wav 
  MPEG mp2,mp3,mpga : audio/mpeg
  MPEG stream source   : audio/x-mpegurl
I have also found that audio/mpeg is used for both file as well as streaming audio.

So my final conclusion is this:
  1. Keep <resourceDesc> as defined by the EAS-CAP profile. Add other <resourceDesc>
      labels for adding video and image content to EAS.

  2. Define a strict set of <mimeTypes> to determine file formats for audio, video, images, etc.

  3. Use both <resourceDesc> and <mimeTypes> during CAP to EAS translation
   to determine file vs streaming and file format.

  An added benefit is that this proposal will work for as well for
  video and image content as it does for audio.

----------------------------------------------------------------------------

I have gone to great lengths here to describe the issues as I thought my points
might have some use in a document. Please feel free to adopt them verbatim if needed.

Regards,
Tom Wood

-- 
Tom Wood

*-- Digital Alert Systems --*
Home Office : 801-272-0418  M-Th 9AM-5PM MDT
wood@digitalalertsystems.com
wood@xmission.com