I think the definition of the charset paramter you've given
is pretty confusing.
A parameter definition just says what the parameter means and what
the allowable range of values are. But the definition you give is
full of stuff about the IPP protocol and rules contained in it. If
you can't define a media type independent of the protocol by which
it is transported, then it's pretty suspect as a MIME media type;
the whole point of 'media type' is to make the information objects
independent of their transport.
> IPP/1.0 keywords (eg, attribute names) are encoded in US-ASCII and
> US-English.
You mean 'Keywords within application/ipp bodies'?
> IPP/1.0 string attributes of syntax "text" or "name"
> MAY have values in ANY character set and language, and MUST use
> "charset/language" prefixes, via the method specified in RFC 2184.
Well, while this is interesting, why is it important to repeat this
little bit of the application/ipp media type rules inside the registration
of the charset parameter?
> The required "charset" parameter of the "application/ipp" MIME
> media type MUST be used to specify the default to use when the
> "charset" of a "charset/language" prefix is empty (ie, a single
> quote character).
I think it's odd to make "what something is used for" to be mandatory.
You just mean it the other way around. The default is from the charset
parameter. The parameter is mandatory. All of this MUST-ing and SHOULD-ing
really just gets in the way.
> IPP/1.0 protocol requests and responses MUST
> use a Content-Language header to specify a default to use when the
> "language" of a "charset/language" prefix is empty (ie, a single
> quote character).
This is very confusing in a media type registration. It's not just
'IPP/1.0 protocol requests and responses', is it? It's any mechanism
used to transport this media type MUST specify a default language, too.
> IPP/1.0 protocol requests and responses MAY contain long lines and
> MUST always contain binary data and therefore MUST be encoded
> using Content-Transfer-Encoding: binary.
You're saying 'IPP/1.0 protocol requests' rather than 'application/ipp bodies'
again. And "COntent-Transfer-Encoding" is appropriate for mail and not for
HTTP transport. I think you mean 'must be transfered using an encoding
appropriate for the protocol and binary data'.
At some point in the earlier life of IPP, it made sense to think about
mailing an application/ipp print request to a printer, as a way of initiating
a print job.
> Security considerations:
>
> IPP/1.0 requests and responses MAY be secured via the use of a
> transport layer security protocol (below HTTP/1.1).
No, 'security considerations' doesn't mean 'encryption used'. What it is used
for is "what risks are entailed by accepting one of these bodies and trying
to interpret it?". For example, application/postscript has a security
consideration that some postscript programs could maliciously delete files
on your print system or tie up your printer or otherwise do harm unless
you're careful. What attacks could be mounted by a print client onto a print
server, and what have you done to protect against them?
> Interoperability considerations:
>
> IPP/1.0 Printer objects (ie, servers) MUST support the attributes
> "printer-charset-supported" (MAY be multi-valued) and
> "printer-natural-language-supported" (MAY be multi-valued), to
> facilitate interoperability with IPP/1.0 clients.
Is there an interoperability considerations section in a media type
registration?
Is this new? What are you trying to say here?
> Intended usage:
>
> COMMON
Actually, no, the intended use of application/ipp is with a very narrow
domain: within an implementation of IPP that tries to bundle a request/response
protocol inside a MIME object body and tunnel it through using HTTP.
So, it's a narrow intended use, and you probably should say so.
Regards,
Larry
-- http://www.parc.xerox.com/masinter