CAP v1.1 IPAWS Profile

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