Subject: IPP> Re: MOD - Proposed application/ipp registration text

From: [email-masked] (Ira Mcdonald x10962)
Date: Fri, 10 Oct 1997 07:36:38 PDT

Hi Larry,

Thanks for your helpful comments.  It seems to me that, from mixed
signals received from Keith Moore and others, IPP will probably
abandon the use of a 'charset' parameter in its MIME type and
abandon any use of (or mapping to/from) Content-Language and
Accept-Charset|Language headers.  

The 'advantages' of using HTTP/1.1 as the initial transport
protocol for IPP/1.0 are contracting steadily: security (but
TLS isn't finished and adopted as a standard), useful HTTP
headers (but we get continuously conflicting advice from
the experts about their use), conveying the target URL
(but this is just one operational attribute, easily bound
into the body of the IPP message itself), character set
and language negotiation (but a multi-valued 'Content-Language'
header has an ENTIRELY different semantic from a multi-valued
'Accept-Language' header, and the latter are optional anyway).

The template that I used was copied directly from RFC 2048
(the latest MIME registration procedures).  

If we abandon the charset/language info in HTTP/1.1 and
MIME mail headers, then the registration for 'application/ipp'
can be short and simple, ie, it contains an IPP message
body (a request or response).

It is NOT reasonable to transfer IPP requests and their
correlated responses via email - they are synchronous and
have no correlators, as the model and protocol are written.
Two request CANNOT be outstanding from the same client to
the same server at once - while I personally question the
'simplicity' of these restrictions, they are the concensus
of the IPP working group.

We DO plan to register 'application/ipp' when the IPP
specs are advanced, simultaneously, to the IESG/IETF.
I just had the action item to write up possible text
for INCLUSION in the IPP model.

Thanks for your help,
- Ira McDonald (outside consultant at Xerox)
  High North Inc
  906-494-2434

---

From: Larry Masinter <[email-masked]>
Date: Sun, 12 Oct 1997 22:10:13 PDT

I've been thinking about this, also in the light of
comments made in some other internet media type registration
discussions, and I've come to the conclusion that it is
probably a bad idea to rely on the 'charset' attribute of
the 'application/ipp' media type *or* the content-language
attribute of the enclosing MIME message.

While those are the conventional ways of specifying the language
and charset of media types which are not self-contained,
that in fact (as was pointed out by others) it's pretty
unreliable, since the MIME headers can get separated from
the entity body. It's a stopgap for those types like
text/plain which have no other place to put the information.

Since you're defining application/ipp from scratch, this
rule doesn't apply.

On the other hand, it baffles me to try to construct a realistic
scenario where there will be many different charset parameters
for different strings in a single application/ipp message.
Why not just have some part of the wrapper define the default
charset for the entire message?

> have no correlators, as the model and protocol are written.

Email itself has a correlator, mainly the message-id and 
in-reply-to link. I send you a message with a message-id, and
you reply with an in-reply-to header. It's pretty clumsy,
I'll admit.

Larry
-- 
http://www.parc.xerox.com/masinter