Subject: [lamps] RFC 3709bis and audio

From: Stefan Santesson <[email-masked]>
Date: Sat, 15 Jan 2022 13:21:59 +0100

While reviewing the updates to RFC 3709, I realize that we have an issue
with how audio is specified and outlined.

The use of audio files such as mp3 with pre-recorded messages is not how
acessibility is handled in my experience.

The way this typically is handled, in for example web applications, is
to include text and a language tag, and then rely on a local speech
engine to read the content to the user according to the language tag.

However, the good news is that this is very easy to fix in RFC 3709, and
the solution is also backwards compatible.

My proposal is simply to allow (and recommend) that audio data is added
using the MIME type "text;charset=UTF-8" as "mediaType" and using MIME
type "text" only in data URI:s. Alternatively we just use "text" as MIME
type and write in the document that the text content MUST be specified
as the bytes of a UTF-8 encoded string.

When this MIME type is used, the textual content is meant to be
processed by a speech engine as explanatory text to the image.

As language is critical information for a speech engine, we need to
allow reasonable inclusion of LogotypeAudioInfo currently specified as:

LogotypeAudioInfo ::= SEQUENCE {
   fileSize        INTEGER,  -- In octets
   playTime        INTEGER,  -- In milliseconds
   channels        INTEGER,  -- 1=mono, 2=stereo, 4=quad
   sampleRate      [3] INTEGER OPTIONAL,  -- Samples per second
   language        [4] IA5String OPTIONAL }  -- RFC 3066 <https://datatracker.ietf.org/doc/html/rfc3066> Language Tag

To allow for reasonable settings for text input I suggest that we add
conventions for fileSize, playTime and channels, where the value 0 for
all these parameters has the meaning of "unspecified":

LogotypeAudioInfo ::= SEQUENCE {
   fileSize        INTEGER,  -- In octets. 0=unspecified
   playTime        INTEGER,  -- In milliseconds. 0=unspecified
   channels        INTEGER,  -- 0=unspecified, 1=mono, 2=stereo, 4=quad.
   sampleRate      [3] INTEGER OPTIONAL,  -- Samples per second.
   language        [4] IA5String OPTIONAL }  -- RFC 3066 <https://datatracker.ietf.org/doc/html/rfc3066> Language Tag

Example:

LogotypeData {
  LogotypeImage{
    LogotypeDetails{
      mediaType=image/png
      logotypeHash={hash value}
     
logotypeURI=data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==
    }
  }
  LogotypeAudio{
    LogotypeDetails{
      mediaType=ext;charset=UTF-8
      logotypeHash={hash value}
      logotypeURI=data:text,Red dot
    }
    LogotypeAudioInfo {
      fileSize=0
      playTime=0
      channels=0
      language=en
    }
  }
}

Implementing audio support in a web application now becomes very easy.
The image would go into an <img> tag, the language in a "lang" attribute
and the audio text in an "alt" attribute like:

<img
src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg=="
lang="en" alt="Red dot" />

-- 
________________
Stefan Santesson

---

From: Russ Housley <[email-masked]>
Date: Sat, 15 Jan 2022 13:21:53 -0500

Stefan:

Does the media type of "text/plain" make more sense in this context?

Russ

> On Jan 15, 2022, at 7:21 AM, Stefan Santesson <[email-masked]> wrote:
> 
> While reviewing the updates to RFC 3709, I realize that we have an issue with how audio is specified and outlined.
> 
> The use of audio files such as mp3 with pre-recorded messages is not how acessibility is handled in my experience.
> 
> The way this typically is handled, in for example web applications, is to include text and a language tag, and then rely on a local speech engine to read the content to the user according to the language tag.
> 
> However, the good news is that this is very easy to fix in RFC 3709, and the solution is also backwards compatible.
> 
> 
> 
> My proposal is simply to allow (and recommend) that audio data is added using the MIME type "text;charset=UTF-8" as "mediaType" and using MIME type "text" only in data URI:s. Alternatively we just use "text" as MIME type and write in the document that the text content MUST be specified as the bytes of a UTF-8 encoded string.
> 
> When this MIME type is used, the textual content is meant to be processed by a speech engine as explanatory text to the image. 
> 
> As language is critical information for a speech engine, we need to allow reasonable inclusion of LogotypeAudioInfo currently specified as:
> 
> To allow for reasonable settings for text input I suggest that we add conventions for fileSize, playTime and channels, where the value 0 for all these parameters has the meaning of "unspecified":
> 
>       logotypeURI=data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg== <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==>
>     }
>   }
>   LogotypeAudio{
>     LogotypeDetails{
>       logotypeURI=data:text,Red <data:text,Red> dot
>     }
>     LogotypeAudioInfo {
>       fileSize=0
>       playTime=0
>       channels=0
>       language=en
>     }
>   }
> }
> Implementing audio support in a web application now becomes very easy. The image would go into an <img> tag, the language in a "lang" attribute and the audio text in an "alt" attribute like:
> 
> <img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==> lang="en" alt="Red dot" />
> 
> 
> 
> 
> 
> 
> -- 
> ________________
> Stefan Santesson
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 15 Jan 2022 22:15:39 +0100

Russ

Yes thank you.

My bad. Yes, there should be a subtype as well so
text/plain;charset=UTF-8 for MIME type and text/plain for data URI would
work nicely.

/Stefan

Den 2022-01-15 kl. 19:21, skrev Russ Housley:
>> While reviewing the updates to RFC 3709, I realize that we have an
>> issue with how audio is specified and outlined.
>>
>> The use of audio files such as mp3 with pre-recorded messages is not
>> how acessibility is handled in my experience.
>>
>> The way this typically is handled, in for example web applications,
>> is to include text and a language tag, and then rely on a local
>> speech engine to read the content to the user according to the
>> language tag.
>>
>> However, the good news is that this is very easy to fix in RFC 3709,
>> and the solution is also backwards compatible.
>>
>>
>> My proposal is simply to allow (and recommend) that audio data is
>> added using the MIME type "text;charset=UTF-8" as "mediaType" and
>> using MIME type "text" only in data URI:s. Alternatively we just use
>> "text" as MIME type and write in the document that the text content
>> MUST be specified as the bytes of a UTF-8 encoded string.
>>
>> conventions for fileSize, playTime and channels, where the value 0
>> for all these parameters has the meaning of "unspecified":
>>
>> Implementing audio support in a web application now becomes very
>> easy. The image would go into an <img> tag, the language in a "lang"
>> attribute and the audio text in an "alt" attribute like:
>>
>> <img