Subject: Re: IPP> ADM - Wake Up Call

From: [email-masked] (Ira Mcdonald x10962)
Date: Sat, 3 Jan 1998 08:03:04 PST

Hi Carl-Uno,

Do you envision conference calls (to help sort out our few
remaining issues and any edits that should have made it into
the most recent Model and Protocol specs but didn't, for
example the range of request-ID being '1..n' and not '0..n')?

The note you forwarded with minutes from the most recent TLS
WG meeting were interesting.  Right at the end, there is a
discussion that if TLS negotiation FAILS, then the new TLS
spec does NOT say you must drop the (TCP) connection - it just
says you must drop TLS - isn't this the moral equivalent of
'null_null_null' (ie, falling back to straight HTTP)?

Happy New Year,
- Ira McDonald (outside consultant at Xerox)
  716-442-0609
------------------------------------------
>From [email-masked] Fri Jan  2 17:18:09 1998
Date: Fri, 2 Jan 1998 13:41:04 PST
To: [email-masked]
From: Carl-Uno Manros <[email-masked]>
Subject: IPP> ADM - Wake Up Call
Sender: [email-masked]
Status: R

Hi all,

I hope you have had a relaxing holiday season and are prepared to help
resolving the last couple of issues that we were too exhausted to tackle
before Christmas.

Please look at the latest drafts of the Model document (just got published
by the IETF) and the Protocol document (which is still in the IETF queue,
but you can get it from the IPP FTP site). Both are dated December 19, 1997.

As far as I am aware there are only two remaining subjects on which we
still need to reach consensus:

1) Should we specify a SHOULD or a SHALL for IPP client support of TLS?

The recommendation out of IETF in Washingtomn was to make it a SHALL, but
that was later challenged on the DL. After Harold's latest contribution in
this discussion, the editors felt that SHOULD would more appropriately
reflect the view of the WG, but I will need confirmation from you that this
is correct. 
Randy Turner has already expressed as his view to stay with the SHALL to
maximize inter-operability.

2) Can we avoid having two differeent URIs for the same IPP printer?

Bob Herriot pointed out the problems with two different URIs (one for HTTP
and one for HTTPS) and suggested a solution. Randy Turner came up with a
counter proposal for solving the problem using HTTP's redirection feature.
See the DL contributions on December 19-20. Personally I would like to have
some of this prototyped to make sure we are on firm ground before making
any final changes.

Let us tackle these two issues with renewed power so we can fix this and
get the drafts off to the IESG ASAP.

I wish you all a Happy New Year,

Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: Tom Hastings <[email-masked]>
Date: Mon, 5 Jan 1998 08:47:37 PST

>example the range of request-ID being '1..n' and not '0..n')?

Ira,
The Protocol document was changed in section 3.6 to make the example value
for clients that aren't using it be the constant 1, instead of 0, 
so that its value is a legal value as agreed to align with the Job MIB and
the SNMP requirement not to use 0 as a table index value.

However, the ABNF fails to specify the syntax of the request-id token.
(0 or 1).  It should be SIGNED-INTEGER, as all four octet integers are, 
but with some restriction on the range to be 1 to 2**31-1.

Also I would think that section 3.6 should also include the range limits,
as has been done for other fields.

Also the Model document doesn't seem to mention the request-id at all,
that I could find.  I'm not sure whether it should or not, since the
request-id is more of a protocol mechanism.

Thanks,
Tom

snip...

---

From: Tom Hastings <[email-masked]>
Date: Mon, 5 Jan 1998 13:12:13 PST

>request-id is more of a protocol mechanism.

I found where "request id" is specified in the Model document.  Its in
section 3.1.1.  In the protocol document, its called "request-id", but
is called "request id" in the Model document (which is why I didn't
find it when searching the Model document).  However, the lower bound
is still specified as 0 to 2**31-1 in section 3.1.1 in the Model document
and needs to be changed to be: 1 to 2**31-1 as agreed.

Perhaps the protocol document section 3.6 should also be fixed to mention
the "request id" in the model document as mapping to the "request-id"
in the protocol document?