Re: [MMUSIC] Comments on ABNF in 4566bis

[Colin Perkins <[e-mail]>]

On 3 Dec 2014, at 18:07, Paul Kyzivat <[e-mail]> wrote:
> On 12/1/14 6:39 PM, Colin Perkins wrote:
> 
>>>> *a=charset:*
>>>> - This is a name from the registry at
>>>> http://www.iana.org/assignments/character-sets/character-sets.xhtml and needs to follow that syntax
>>> 
>>> In this and other cases where what goes in the SDP is a reference to something defined in a registry, I am inclined to give a simplified syntax that might be a superset of what is permitted in the registry. It doesn't matter a whole lot if it allows some invalid values, because such names will never be in the registry.
>>> 
>>> This will help implementers. And when the exact formal definition isn't available in ABNF, or is very complex, it can also ease formal checking of the SDP ABNF.
>>> 
>>> Given that explanation, is there anything wrong with what I have?
>> 
>> Why not reference the correct ABNF from RFC 2978? I don’t understand the desire to put something incorrect here.
> 
> I've looked again at 2978, and it is less than clear. It says:
> 
>   Each assigned name MUST uniquely identify a single charset.  All
>   charset names MUST be suitable for use as the value of a MIME content
>   type charset parameter and hence MUST conform to MIME parameter value
>   syntax.  This applies even if the specific charset being registered
>   is not suitable for use with the "text" media type.
>   ...
>   Finally, charsets being registered for use with the "text" media type
>   MUST have a primary name that conforms to the more restrictive syntax
>   of the charset field in MIME encoded-words [RFC-2047, RFC-2184] and
>   MIME extended parameter values [RFC-2184].  A combined ABNF
>   definition for such names is as follows:
> 
>     mime-charset = 1*mime-charset-chars
>     ...
> 
> The final paragraph above seems to say that mime-charset only applies for charsets registered for use with "text", but based on the first paragraph this syntax could apply for all charset names.
> 
> And this syntax doesn't apply any limit to how long the names can be, while the IANA registry itself says:
> 
>   The character set names may be up to 40 characters taken from the
>   printable characters of US-ASCII.  However, no distinction is made
>   between use of upper and lower case letters.
> 
> I based my ABNF on that. But yes, I could reference mime-charset from 2978.
> 
> Note also that I currently reference "Preferred MIME Name", but have a note asking if I should instead be referencing "Name". These are references to column headings in the table in the registry, for lack of something better to reference. Looking again at the registry, I think I need instead to say:
> 
> OLD:
> 
>   The charset specified MUST be one of those registered with IANA, such
>   as ISO-8859-1.  The character set identifier is a US-ASCII string and
>   MUST be compared against the IANA identifiers using a case-
>   insensitive comparison.  If the identifier is not recognised or not
>   supported, all strings that are affected by it SHOULD be regarded as
>   octet strings.
> 
> NEW:
> 
>   The charset specified MUST be one of those registered in the IANA
>   Character Sets registry
>   (http://www.iana.org/assignments/character-sets) such
>   as ISO-8859-1.  The character set identifier is a US-ASCII string and
>   MUST be compared against identifiers from the "Name" or "Preferred
>   MIME Name" field of the registry using a case-insensitive
>   comparison.  If the identifier is not recognised or not supported,
>   all strings that are affected by it SHOULD be regarded as octet
>   strings.
> 
> I think this is needed because the identifiers in the "Preferred MIME Name" field are not repeated in the "Name" field, but both are allowed to be used in references.

I expect the charset community has common practices in this area. It might be worth asking the designated expert for the registry what’s the preferred field to match on, and how to reference the name syntax. Alternatively, the APPS area director can likely suggest a reviewer who can advise on the right thing to do.

-- 
Colin Perkins
https://csperkins.org/