Subject: Re: IPP>MOD Status code for URI's too long?

From: Van Dang <[email-masked]>
Date: Tue, 12 May 1998 12:18:54 -0700 (PDT)

If I interpret the IPP/1.0 Model and Semantics document
section 13.1.4.10 correctly, the error "client-error-request-
uri-too-long (0x0409)", should be used when a uri attribute
length is <= 1023 bytes but greater than the length that is
supported by the IPP object.  In the case where the uri
attribute length actually exceeds 1023, the error returned
should be "client-error-bad-request (0x0400)".

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.

Date: Mon, 11 May 1998 14:57:19 -0700
To: Carl Kugler <[email-masked]>, <[email-masked]>
>From: Robert Herriot <[email-masked]>
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: [email-masked]

--=====================_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"

<html>
<font size=3>I cannot remember why we introduced it.&nbsp; But after
talking with Tom, I would <br>
support changing the message 'client-error-request-uri-too-long'&nbsp; to
<br>
'client-error-request-value-too-long' and have it apply to all types that
<br>
are text-like, namely text, name, charset, language, keywork, uri, <br>
uri-scheme, mime-media-type, text-with-language, and
name-with-language.&nbsp; <br>
This message would be returned like 'bad-request' and indicate that no
<br>
processing was going to take place, but it would give a user a bit more
<br>
information about why theclient isn't behaving.&nbsp; In the case of
<br>
'client-error-request-value-too-long', the user might realize that if he
<br>
sent in a short text field, things would work.<br>
<br>
<br>
Bob Herriot<br>
<br>
<br>
At 02:35 PM 5/11/98 , Carl Kugler wrote:<br>
&gt;I agree that it would be simpler to return 'client-error-bad-request'
whenever<br>
&gt;an attribute fails the length test.&nbsp; Why was<br>
&gt;'client-error-request-uri-too-long' introduced in the first
place?&nbsp; If there is<br>
&gt;strong consensus that we don't need it, can we change the
document?<br>
&gt;<br>
&gt; -Carl<br>
&gt;<br>
&gt;<br>
&gt;C<br>
&gt; </font><br>
</html>

--=====================_12281369==_.ALT--