We can change "client-error-request-uri-too-long" to
"client-error-request-value-too-long" to include the cases
for text and name attributes, but its use should indicate
that the attribute value itself conforms to the IPP boundary
limit, but might be too big for the IPP object to process.
Van D.
Received: from hprnd.rose.hp.com (daemon@hprnd.rose.hp.com [15.29.43.139]) by thunder.rose.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id PAA10416 for <vandang@thunder.rose.hp.com>; Mon, 11 May 1998 15:10:09 -0700 (PDT)
Received: from atlrel2.hp.com by hprnd.rose.hp.com with ESMTP
(1.37.109.20/15.5+ECS 3.3) id AA157884600; Mon, 11 May 1998 15:10:01 -0700
Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30])
by atlrel2.hp.com (8.8.6/8.8.5tis) with ESMTP id SAA19071;
Mon, 11 May 1998 18:09:18 -0400 (EDT)
Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id SAA10084; Mon, 11 May 1998 18:03:13 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Mon, 11 May 1998 18:01:35 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA09827 for ipp-outgoing; Mon, 11 May 1998 17:56:51 -0400 (EDT)
Message-Id: <199805112153.OAA07000@woden.eng.sun.com>
X-Sender: rherriot@woden.eng.sun.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1
Date: Mon, 11 May 1998 14:57:19 -0700
To: Carl Kugler <kugler@us.ibm.com>, <ipp@pwg.org>
>From: Robert Herriot <robert.herriot@Eng.Sun.COM>
Subject: Re: IPP>MOD Status code for URI's too long?
In-Reply-To: <5030100020354752000002L022*@MHS>
Mime-Version: 1.0
Content-Type: multipart/alternative;
types="text/plain,text/html";
boundary="=====================_12281369==_.ALT"
Sender: owner-ipp@pwg.org
--=====================_12281369==_.ALT
Content-Type: text/plain; charset="us-ascii"
I cannot remember why we introduced it. But after talking with Tom, I would
support changing the message 'client-error-request-uri-too-long' to
'client-error-request-value-too-long' and have it apply to all types that
are text-like, namely text, name, charset, language, keywork, uri,
uri-scheme, mime-media-type, text-with-language, and name-with-language.
This message would be returned like 'bad-request' and indicate that no
processing was going to take place, but it would give a user a bit more
information about why theclient isn't behaving. In the case of
'client-error-request-value-too-long', the user might realize that if he
sent in a short text field, things would work.
Bob Herriot
At 02:35 PM 5/11/98 , Carl Kugler wrote:
>I agree that it would be simpler to return 'client-error-bad-request' whenever
>an attribute fails the length test. Why was
>'client-error-request-uri-too-long' introduced in the first place? If there
is
>strong consensus that we don't need it, can we change the document?
>
> -Carl
>
>
>C
>
--=====================_12281369==_.ALT
Content-Type: text/html; charset="us-ascii"
I cannot remember why we introduced it. But after
talking with Tom, I would
support changing the message 'client-error-request-uri-too-long' to
'client-error-request-value-too-long' and have it apply to all types that
are text-like, namely text, name, charset, language, keywork, uri,
uri-scheme, mime-media-type, text-with-language, and
name-with-language.
This message would be returned like 'bad-request' and indicate that no
processing was going to take place, but it would give a user a bit more
information about why theclient isn't behaving. In the case of
'client-error-request-value-too-long', the user might realize that if he
sent in a short text field, things would work.
Bob Herriot
At 02:35 PM 5/11/98 , Carl Kugler wrote:
>I agree that it would be simpler to return 'client-error-bad-request'
whenever
>an attribute fails the length test. Why was
>'client-error-request-uri-too-long' introduced in the first
place? If there is
>strong consensus that we don't need it, can we change the
document?
>
> -Carl
>
>
>C
>
--=====================_12281369==_.ALT--