[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency-comment] CAP v1.1 IPAWS Profile
Thanks Tom, We think we have covered your issues in the work we've conducted on the document since Jan. 20, but we suggest that you review the Public Review document when it is released, and post any comments on the document you have at that time. Thank you for your comment, Rex Brooks >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>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/>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>http://mywebsite.net/audiofile.wav >or ><http://mywebsite.net/audiofile.mp3>http://mywebsite.net/audiofile.mp3 >or ><http://mywebsite.net:8000/audiofile.mp3>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 ><mailto:wood@digitalalertsystems.com>wood@digitalalertsystems.com ><mailto:wood@xmission.com>wood@xmission.com -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-898-0670
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]