Subject: Suggested text for the state syntax in IPP V0.92

From: Tom Hastings <[email-masked]>
Date: Fri, 22 Nov 1996 11:50:17 PST

I've attached revisions to section 6.1 Attribute Syntax as .doc and .pdf

I will post the files in  \new\ipp92syn.doc and .pdf
as soon as I can, but I was unable to change directories
when logging into the PWG server so I could not post any documents!  
I was able to read documents using anonymous ftp though.
I have a call into Jay and Jeff who are off-side for a few hours.

A number of data syntaxes have the word State tacked on the end of
them.  The idea is that these data syntax values are used for the
xxx-supported attributes of the printer object and indicate whether
the supported value is ready or not, i.e., whether human intervention
is needed in order for a job to use that value or not.

I think that it is probably most useful to only indicate values
that are not ready, rather than values that are, though that may be
arguable.

So the media-supported printer attribute might contain values like:

  media-supported=na-letter-white, na-letter-transparent, b:not-ready

Meaning that na-letter-white and na-letter-transparent are loaded into the 
two trays of the output device and that b is supported but requires the
operator to change the trays.

We could even have a third value: on-order
meaning that it will take even longer, but your job will print eventually.

and a fourth value: special-order
meaning that the provider will initiate a special order when the job
is submitted and your job will print eventually.

So I have attached my suggestions to fix the text in section 6.1

Here is the current contents in plain text without formatting:

string	arbitrary ASCII strings, no control characters, except <SPACE>.TBD
stringPair	string ":" string
stringState	string state
name	arbitrary ASCII strings, no control characters, and no <SPACE>
characters.TBD
URL	Universal Resource LocatorTBD
dateTime	date and time in RFC 822 formatTBD
deltaTime	[hours ":"] minutes
cardinal	0 .. n represented as ASCII digits
type1Enum	standard names, must revise the IPP standard to add a new name.
No private names are allowed.TBD
type2Enum	standard names, but an implementor can add new TBDby proposing
them to the PWG for registration (or an IANA-appointed registry advisor
after the PWG is no longer certified) anytime.  IANA keeps the registry.
Implementors can add private (un-registered) with a suitable distinguishing
prefix, such as -xxx- where xxx is the company name registered with IANA.
type3Enum	standard names, but an implementor can add new names by submitting
a registration request directly to IANA, no PWG or IANA-appointed registry
advisor review is required.  Implementors can add private (un-registered)
names with a suitable distinguishing prefix, such as -xxx- where xxx is the
company name registered with IANA.TBD
type2EnumState	type2Enum state
type3EnumState	type3Enum state
state	TBD
Boolean	tokens: yes, y, true, or t and no, n, false, or f.TBD
positiveInteger	1 .. n represented as ASCII digitsTBD
positiveIntegerCross	positiveInteger [ "x" positiveInteger ]
positiveIntegerCrossState	positiveIntegerCross state
positiveIntegerRange	positiveInteger  ":" positiveInteger
positiveIntegerUnits	positiveInteger units
positiveIntegerState	positiveInteger state
units	"ppm" | "ipm" | "spm" | "cps" | "lpm"
type3Locale	type3Country ":" type3Language ":" type3CodeSet
type3Country	type3Enum
type3Language	type3Enum
type3CodeSet	type3Enum
type2Format	name [ "/" version ]
version	name
type3LocaleState	type3Locale state

My suggestion is to define a new data syntax: State which begins
with a capital letter, so that it cannot be used by itself, only
in combination with other syntaxes in the above table.

State       [:not-ready] / [:on-order] / [:special-order]

---

From: Jeff Schnitzer <[email-masked]>
Date: Fri, 22 Nov 1996 17:44:36 -0500

> I have a call into Jay and Jeff who are off-side for a few hours.
Tom has placed the files on the FTP server.

In closing a security hole with anonymous FTP on the PWG server, I
broke the "root" of the pwg account.  UNTIL I FIX THIS PROBLEM, YOU
MAY SEE THE PATH TO THE PWG TREE AS /home/ftp/pub/pwg RATHER THAN
JUST /pub/pwg [This is what broke Tom's scripts].  Otherwise, both
anonymous FTP and the pwg account work as before.

/Jeff

---------------------------------------------------------------
Jeffrey D. Schnitzer      |   Email:  [email-masked] 
Underscore, Inc.          |   Voice:  (603) 889-7000
41-C Sagamore Park Rd     |     Fax:  (603) 889-2699   
Hudson, NH  03051-4915    |     Web:  http://www.underscore.com
---------------------------------------------------------------