IPP> MOD & IIG - Issues found by Genoa in IPP/1.0 Model spec and Imple menter's Guide

IPP> MOD & IIG - Issues found by Genoa in IPP/1.0 Model spec and Imple menter's Guide

IPP> MOD & IIG - Issues found by Genoa in IPP/1.0 Model spec and Imple menter's Guide

Hastings, Tom N hastings at cp10.es.xerox.com
Fri Aug 20 00:20:29 EDT 1999


Mike,

Thanks for forwarding these issues to us that your team found while
implementing your IPP Test Suite.

These issues are with the IPP/1.0 Model and Semantics document and the
IPP/1.0 Implementer's Guide  (IIG).  I've responded to each of the three
issues.  See lines beginning with TH>.

Please send any more that you may find.

Tom

IPP/1.0 issues

It seems there is a contradiction between the [RFC2566], [RFC2639] on one
side and "IPP Bake-Off Results Summary" (both #1 and #2) on the other side,
regarding "copies-supported" Job Template attribute syntax. The first two
documents indicate rangeOfInteger (1:MAX) and the last ones specify integer.
Finally I have chosen the rangeOfInteger syntax in my implementation.
TH>  Correct.  The RFC should take precedence over the notes from the
bakeoff.


'client-error-uri-scheme-not-supported' error handling is very unclear and
inconsistent.  

E.g. From [RFC 2639]: (the IPP/1.0 IIG)

"server-error-uri-scheme-not-supported:  the URI scheme supplied in the
"document-uri" operation attribute is not supported and is returned in the
Unsupported Attributes group." (Page 40,  section 2.3.1.2.  Print-URI)

"server-error-uri-scheme-not-supported:  the URI scheme supplied in the
"document-uri" operation attribute is not supported and the "document-uri"
attribute MUST be returned in the Unsupported Attributes group."  (Page  43,
section 2.3.2.2  Send-URI)
I've edited the IPP/1.1 IIG (two places above)  to correct this to agree
with RFC 2566.

"document-uri (uri)
IF NOT a single non-empty 'uri' value, REJECT/RETURN
'client-error-bad-request'.
IF the value length is greater than 1023 octets, REJECT/RETURN
'client-error-request-value-too-long'.
IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-request'.
IF scheme is NOT in the Printer object's "reference-uri-schemes-supported"
attribute, REJECT/RETURN 'client-error-uri-scheme-not-supported'.

The Printer object MAY check to see if the document exists and is
accessible.  If the document is not found or is not accessible,
REJECT/RETURN 'client-error-not-found'." 
(Page 22,  section 2.2.1.5   Validate the values of the REQUIRED Operation
attributes)

There are also another two references to
'client-error-uri-scheme-not-supported' in this document.

The document [RFC 2566] contains only one reference:
"13.1.4.13 client-error-uri-scheme-not-supported (0x040C)

The type of the client supplied URI in a Print-URI or a Send-URI  operation
is not supported." 
(Page 151)

I assume the correct keyword for this error is
'client-error-uri-scheme-not-supported' and if it is happening the
Unsupported Attributes group should contain the "document-uri" attribute. 
TH> I agree that the proper name for the error is
'client-error-uri-scheme-not-supported', not
'server-error-uri-scheme-not-supported'., since the error is defined in
section 13.1.4, not 13.15.  When an error is a
'client-error-xxx-not-supported' versus server-error-xxx-not-supported' is
not very clear.  However, the current rule of thumb for allocating the names
for xxx-not-supported errors seems to be:  If the feature is defined in the
standard, but is OPTIONAL, then the 'server-error-xxx-not-supported' is
used.  However, if the value is one of an open ended list, such as
document-format, compression, or uri-schemes, then we use the
'client-error-xxx-not-supported' in the definition.

TH> However, I disagree that the "document-uri" SHOULD be returned.  Section
3.1.6.1 of IPP/1.1 indicates that the "document-uri" NEED NOT be returned,
since this error has its own status code.  I think that section 3.1.7 needs
a reference back to this table in section 3.1.6.  I'll add such a reference
when the RFC Editor sends us the IPP/1.1 RFC for proof reading.
 



About "document-natural-language" attribute validations
In [RFC 2639] (IPP/1.0 IIG) it is stated:
"IF NOT a value that the Printer object supports in document formats, (no
corresponding "xxx-supported" Printer attribute), REJECT/RETURN
'client-error-natural-language-not-supported'." (Page 24)

In [RFC 2566]:
"The client OPTIONALLY supplies this attribute.  The Printer object
OPTIONALLY supports this attribute. This attribute specifies the natural
language of the document for those document-formats that require a
specification of the natural language in order to image the document
unambiguously. There are no particular values required for the Printer
object to support." (Page 36) 

"document-natural-language" (naturalLanguage):
The client OPTIONALLY supplies this attribute.  The Printer object
OPTIONALLY supports this attribute.  This attribute specifies the natural
language of the document for those document-formats that require a
specification of the natural language in order to image the document
unambiguously.  There are no particular values required for the Printer
object to support." (Page 52)
I'm afraid I don't see the problem here.  The IIG is saying that there is no
"xxx-supported" Printer attribute that indicates which natural languages are
supported for a document.

  



More information about the Ipp mailing list