FYI... I will take care of supplying the updates they have requested...
> Begin forwarded message:
>> From: Amanda Baber via RT <iana-mime at iana.org>
> Subject: [IANA #955632] Request for media type text/strings
> Date: April 13, 2017 at 12:59:03 PM EDT
> To: msweet at apple.com> Reply-To: iana-mime at iana.org>> Hi Michael,
>> The designated experts have returned a review for this request (see inline comments below). Your other request is still in their queue. I'll send them a reminder now.
>> Please send a revised security considerations section with your reply.
>> Best regards,
>> Amanda Baber
> Lead IANA Services Specialist
>>> Name: Michael Sweet
>> Email: msweet at apple.com>>> Media type name: text
>> Media subtype name: strings
>> This name is acceptable, although I have to at least suggest that a more
> specific name, e.g., application/printer-message-catalog might be
> something to consider. (My personal preference would be the leave the name
> alone, but as reviewer I am obligated to make the suggestion.)
>> The fact that this essentially a registration of Apple's .strings
> file format, the more general name is OK, but does place a bit more
> of a requirement on the registration to cover all the issues.
>>> Required parameters: NONE
>>> Optional parameters:
>>> Encoding considerations: 8bit
>>> UTF-8 encoded Unicode text.
>>> Security considerations:
>>> Localized strings may be arbitrarily large and could potentially cause a
>>> Localized strings may contain printf-style format characters that could cause
>> a program to display unintended information or crash.
>> This is useful information but not sufficient. All media types must:
>> (1) State whether or not the media type contains active or executable
> content. If the media type does contain executable content explain
> what measures have been taken to insure that it can be executed
> safely, e.g. a sandbox, safe operation set, signed content, etc.
>> (2) State whether or not the information contained in the media type
> needs privacy or integrity services.
>> (3) If the answer to (2) is yes, elaborate on any privacy or integrity
> services the media type itself provides, or if it doesn't provide such
> services, explain how they should be provided externally, e.g., through
> the use of SSL/TLS.
>> The answer to (1) is pretty clearly "no", but that needs to be stated. As for
> (2) and (3), the format clearly doesn't provide integrity or privacy
> protections. I don't think privacy is an issue - and you should say that if
> it's true - but integrity clearly is, so there needs to be something about how
> this kind of protection is achieved in the wild.
>>> Interoperability considerations:
>>> Published specification:
>>http://ftp.pwg.org/pub/pwg/candidates/cs-ippjobprinterext3v10-20120727-5100.13.pdf>> Is the candidate URL going to change to something else at some point?
>>> Applications which use this media:
>> All Cocoa, NeXTStep, and OpenStep applications
>> IPP Everywhere
>>> Fragment identifier considerations:
>>> Restrictions on usage:
>>> Provisional registration? (standards tree only):
>>> Additional information:
>>> 1. Deprecated alias names for this type: NONE
>> 2. Magic number(s): NONE
>> 3. File extension(s): NONE
>> 4. Macintosh file type code: NONE
>> 5. Object Identifiers: NONE
>>> General Comments:
>>>> Person to contact for further information:
>>> 1. Name: ISTO-PWG Internet Printing Protocol Workgroup
>> 2. Email: ipp at pwg.org>>> Intended usage: Common
>> Used for providing localizations of English keywords and numeric values.
>>>> Author/Change controller: The Printer Working Group
>> c/o The IEEE Industry Standards and Technology Organization
>> 445 Hoes Lane
>> Piscataway, NJ 08854
Michael Sweet, Senior Printing System Engineer
-------------- next part --------------
An HTML attachment was scrubbed...