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.