RFC 3381
Internet Printing Protocol (IPP): Job Progress Attributes
Internet Printing Protocol (IPP): Job Progress Attributes 🖨️✨
okay bestie, welcome to RFC 3381 💖 this one is all about how a printer tells you how far along your print job is. so iconic. 🦋
The title block tea ☕: this is a Standards Track document from the Network Working Group, dated September 2002. It was written by T. Hastings from Xerox Corporation, H. Lewis from IBM Printing Company, and R. Bergman from Hitachi Koki Imaging Solutions. It updates RFC 2910. The title block doesn't list anything it obsoletes, so nothing gets retired here. 🎀
Status of This Memo 📜
bestie, this part is the official-ish bit, but it's important 🫶 This document specifies an Internet standards track protocol for the Internet community, and it requests discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 🌸
Copyright Notice 🎀
Copyright (C) The Internet Society (2002). All Rights Reserved. ✨
Abstract 🦋
okay so the abstract is giving very clear main character energy 👑 It defines four new Job Description attributes for monitoring job progress. These are registered as OPTIONAL extensions to the Internet Printing Protocol, which is IPP/1.0 and IPP/1.1. The attributes are drawn from the PWG Job Monitoring MIB. 💅
It also defines a new sheet-collate Job Template attribute. That one controls sheet collation and helps you interpret the job progress attributes. Obsessed 😭
Table of Contents 📚
1 Introduction.....................................................2
2 Terminology......................................................2
2.1 Conformance Terminology........................................4
2.2 Other terminology..............................................4
3 Job Template attributes..........................................4
3.1 sheet-collate (type2 keyword)..................................4
4 IPP Job Description attributes for monitoring Job Progress.......6
4.1 job-collation-type (type2 enum)................................9
4.2 sheet-completed-copy-number (integer(0:MAX))..................11
4.3 sheet-completed-document-number (integer(0:MAX))..............11
4.4 impressions-completed-current-copy (integer(0:MAX))...........11
5 Conformance Requirements........................................11
6 IANA Considerations.............................................12
6.1 Attributes....................................................
6.2 Keyword Attribute Values......................................
6.3 Enum Attribute Values.........................................
7 Internationalization Considerations.............................12
8 Security Considerations.........................................12
9 References......................................................12
10 Description of the Base IPP Documents..........................13
11 Authors' Addresses.............................................15
12 Full Copyright Statement.......................................161. Introduction 🌈
so this section is the setup 💖 It defines the same four new Job Description attributes for monitoring job progress. They're registered as OPTIONAL extensions to IPP/1.0 [RFC2566] and IPP/1.1 [RFC2911]. The attributes are drawn from the PWG Job Monitoring MIB [RFC2707]. Check section 10 if you want the rundown on the base IPP documents. The new Job Description attributes are:
"job-collation-type" (type2 enum)
"sheet-completed-copy-number" (integer(0:MAX))
"sheet-completed-document-number" (integer(0:MAX))
"impressions-completed-current-copy" (integer(0:MAX))It also defines the new sheet-collate Job Template attribute, which controls sheet collation and helps with reading the job progress attributes. 🎀
Also, these new attributes can be used by themselves, next to the IPP/1.1 job-impressions-completed attribute. They're useful job progress monitoring attributes, and they can also be passed in an IPP Notification (see [ipp-ntfy]). ✨
2. Terminology 📖
bestie, this section is the glossary, and it's where the vocab gets locked in 🔒
2.1. Conformance Terminology 💅
Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to conformance. That meaning is defined in RFC 2119 [RFC2119] and in section 12.1 of [RFC2911]. 🫶
Here's the important part: if an implementation supports the extension defined in this document, then these terms apply. If it doesn't, they don't. These terms define conformance to this document only. They do not affect conformance to other documents, unless explicitly stated otherwise. 🚫
2.2. Other terminology 🧚
This document uses terms like Job object (or Job), IPP Printer object (or Printer), "operation", "attribute", "keyword", "support", and "impression". These terms have special meaning, and they're defined in the model terminology [RFC2911], section 12.2. Ate ✨
3. Job Template attributes 🍓
okay this is where the template stuff lives 🎀
3.1. sheet-collate (type2 keyword) 🦋
Here's the table for the attribute, copied exactly so nothing gets lost in translation:
+===================+======================+=====================+
| Job Attribute |Printer: Default Value| Printer: Supported |
| | Attribute | Values Attribute |
+===================+======================+=====================+
| sheet-collate | sheet-collate-default| sheet-collate- |
| (type2 keyword) | (type2 keyword) | supported (1setOf |
| | | type2 keyword) |
+-------------------+----------------------+---------------------+So this attribute decides whether the media sheets of each copy of each printed document in a job are kept in sequence. That only matters when you ask for multiple copies using the copies attribute. 🌸
Standard keyword values are:
'uncollated': each print-stream sheet is printed a number of times in succession, equal to the value of thecopiesattribute. Then the next print-stream sheet comes up. Chaos energy, but make it organized 🌀'collated': each copy of each document is printed with the print-stream sheets in sequence. Then the next document copy follows. Clean and neat 💖
Let's say a document makes two media sheets and copies is 6. In the 'uncollated' case, six copies of the first media sheet print, followed by six copies of the second. In the 'collated' case, one copy of each of the six sheets prints, then another copy of each of the six media sheets. 🍓
Whether sheet collation is achieved by putting copies in multiple output bins, or in the same bin with implementation defined document separation, is implementation dependent. Same goes for whether it's done by making multiple passes over the job or by using an output sorter. Both are implementation dependent. 🧚
Note: IPP/1.0 [RFC2566] and IPP/1.1 [RFC2911] are silent on whether or not sheets within documents are collated. Thesheet-collate-supportedPrinter attribute lets a Printer object say whether it collates sheets within each document, and whether it lets the client control sheet collation. An implementation can indicate that it supports uncollated sheets, collated sheets, or both. It does that using the'uncollated','collated', or both'uncollated'and'collated'values, respectively. 💜
This attribute is affected by multiple-document-handling. That attribute describes the collation of documents, while sheet-collate describes how individual pages within a document get collated. To explain how these two work together, the spec introduces the term "set". A "set" is a logical boundary between the delivered media sheets of a printed job. 🎀
For example, take a ten page single document with collated pages and a request for 50 copies. Each of the 50 printed copies of the document is a "set". Now in that same example, if the pages were uncollated, then 50 copies of each individual page in the document would each make a "set". 🙈
The table below shows how sheet-collate interacts with multiple document handling:
"sheet- "multiple- Semantics
collate" document-
handling"
'collated' 'single- Each copy of the concatenated
document' documents, with their pages in
sequence, represents a "set".
'collated' 'single- Each copy of the concatenated
document-new- documents, with their pages in
sheet' sequence, represents a "set".
'collated' 'separate- Each copy of each separate
documents- document, with its pages in
collated- sequence, represents a "set".
copies'
'collated' 'separate- Each copy of each separate
documents- document, with its pages in
uncollated- sequence, represents a "set".
copies
'uncollated' 'single- Each media sheet of the document
document' is printed a number of times equal
to the "copies" attribute; which
constitutes a "set".
'uncollated' 'single- Each media sheet of the
document-new- concatenated documents is printed
sheet' a number of times equal to the
"copies" attribute; which
constitutes a "set".
'uncollated' 'separate- This is a degenerate case, and the
documents- printer object MUST reject the job
collated- and return the status, "client-
copies' error-conflicting-attributes".
'uncollated' 'separate- This is a degenerate case, and the
documents- printer object MUST reject the job
uncollated- and return the status "client-
copies error-conflicting-attributes".Bestie, the big takeaway from the table: it's obvious that the implicit value of the sheet-collate attribute, in a printer that doesn't support the sheet-collate attribute, is 'collated.' The semantics of multiple-document-handling are otherwise nonsensical in the case of separate documents. 💀✨
4. IPP Job Description attributes for monitoring Job Progress ✨
okay so this section is all about watching a job's progress 📈🖨️ these attributes are proposed to join IPP through the type2 registration procedures 🎀 they also show up as attributes in the notification content of a notification report [ipp-ntfy] 🔔
there are a bunch of Job Description attributes for tracking progress, and they count how many K octets, impressions, sheets, and pages were requested or completed 💅 for impressions and sheets, "completed" means stacked 🥞 unless the implementation can't detect when each sheet gets stacked, in which case stacked gets approximated as the moment processing of each sheet is done 🫶 there are objects and attributes for the whole job AND for the copy of the document that's currently being stacked 💖 and for that current copy, how fast the counters tick up totally depends on the sheet and document collation of the job 🌸
consider these four Job Description attributes for tracking a job's impressions 👀
"job-impressions-completed"counts the total number of impressions stacked for the job (see [RFC2911] section 4.3.18.2) ✨"impressions-completed-current-copy"counts the number of impressions stacked for the current document copy 🦋"sheet-completed-copy-number"identifies the number of the copy for the current document being stacked, where the first copy is 1 🎀"sheet-completed-document-number"identifies the current document within the job that is being stacked, where the first document in a job is 1 💜 NOTE: this attribute SHOULD NOT be implemented for implementations that only support one document per job 🙈
so let's see how this plays out 👑 for each of the three types of job collation, imagine a job with three copies of two documents (1, 2), where each document has 3 impressions, and the four variables change as each sheet is stacked for one-sided printing 😭 these tables are the receipts 🧾
"job-collation-type" = 'uncollated-sheets(3)'
"job- "impressions- "sheet- "sheet-
impressions- completed- completed- completed-
completed" current-copy" copy-number" document-
number"
0 0 0 0
1 1 1 1
2 1 2 1
3 1 3 1
4 2 1 1
5 2 2 1
6 2 3 1
7 3 1 1
8 3 2 1
9 3 3 1
10 1 1 2
11 1 2 2
12 1 3 2
13 2 1 2
14 2 2 2
15 2 3 2
16 3 1 2
17 3 2 2
18 3 3 2"job-collation-type" = 'collated-documents(4)'
"job- "impressions- "sheet- "sheet-
impressions- completed- completed- completed-
completed" current-copy" copy- document-
number" number"
0 0 0 0
1 1 1 1
2 2 1 1
3 3 1 1
4 1 1 2
5 2 1 2
6 3 1 2
7 1 2 1
8 2 2 1
9 3 2 1
10 1 2 2
11 2 2 2
12 3 2 2
13 1 3 1
14 2 3 1
15 3 3 1
16 1 3 2
17 2 3 2
18 3 3 2"job-collation-type" = 'uncollated-documents(5)'
"job- "impressions- "sheet- "sheet-
impressions- completed- completed- completed-
completed" current-copy" copy-t document-
number" number"
0 0 0 0
1 1 1 1
2 2 1 1
3 3 1 1
4 1 2 1
5 2 2 1
6 3 2 1
7 1 3 1
8 2 3 1
9 3 3 1
10 1 1 2
11 2 1 2
12 3 1 2
13 1 2 2
14 2 2 2
15 3 2 2
16 1 3 2
17 2 3 2
18 3 3 24.1 job-collation-type (type2 enum)
okay the job collation is the combo of sheet collation and document collation 🧩 sheet collation is the ordering of sheets within a document copy 📄 document collation is the ordering of document copies within a multi-document job 📚 the value of "job-collation-type" is affected by the "sheet-collate" Job Template attribute (see section 3.1), if it's supplied and supported 💖
the Standard enum values are:
'1' 'other': not one of the defined values 🤷♀️'2' 'unknown': the collation type is unknown 🌫️'3' 'uncollated-sheets': no collation of the sheets within each document copy 🙅♀️ so each sheet of a document that's making multiple copies gets replicated before the next sheet in the document is processed and stacked 🥞 if the device has an output bin collator, the'uncollated-sheets(3)'value may actually produce collated sheets as far as the user is concerned (in the output bins) ✨ but when the job collation is'uncollated-sheets(3)', job progress looks exactly the same to a monitoring app whether the device has an output bin collator or not 🫠'4' 'collated-documents': collation of the sheets within each document copy happens inside the printing device by making multiple passes over either the source or an intermediate representation of the document 🔁 plus, with multiple documents per job, the i'th copy of each document gets stacked before the j'th copy of each document, so the documents are collated within each job copy 🧚 for example, if a job has documents A and B, the end user gets A, B, A, B, .... this value matches the IPP [RFC2911]separate-documents-collated-copieskeyword value of the"multiple-document-handling"attribute 🎀
if the job's"copies"attribute is '1' (or not supplied), then"job-collation-type"is defined to be '4' 💀
'5' 'uncollated-documents': collation of the sheets within each document copy happens inside the printing device by making multiple passes over either the source or an intermediate representation of the document 🔁 with multiple documents per job, all copies of the first document in the job get stacked before any copies of the next document in the job, so the documents are uncollated within the job 🌈 for example, if a job has documents A and B, the end user gets A, A, ..., B, B, .... this value matches the IPP [RFC2911]separate-documents-uncollated-copieskeyword value of the"multiple-document-handling"attribute 🍓
4.2 sheet-completed-copy-number (integer(0:MAX))
this is the number of the copy being stacked for the current document 🎀 it starts at 0, gets set to 1 when the first sheet of the first copy for each document is being stacked, and equals n when it's the nth sheet stacked in the current document copy 🌸 if the value is unknown, the Printer MUST return the 'unknown' out-of-band value (see [RFC2911] section 4.1), rather than the -2 value used in some MIBs [RFC2707] 🙅♀️ no -2s allowed, bestie 💅
4.3 sheet-completed-document-number (integer(0:MAX))
this one is the ordinal number of the document in the job that's currently being stacked 📚 it starts at 0, increments to 1 when the first sheet of the first document in the job is being stacked, and equals n when it's the nth document in the job, starting with 1 🧁 if the value is unknown, the Printer MUST return the 'unknown' out-of-band value (see [RFC2911] section 4.1), rather than the -2 value used in some MIBs [RFC2707] 💜
implementations that only support one document job SHOULD NOT implement this attribute 🙈 it's giving "not needed here" energy 🫶
4.4 impressions-completed-current-copy (integer(0:MAX))
this is the number of impressions the device has completed for the current copy of the current document so far 🦋 for printing, completed impressions include interpreting, marking, and stacking the output ✨ for other types of job services, completed impressions include the number of impressions processed 🧚 if the value is unknown, the Printer MUST return the 'unknown' out-of-band value (see [RFC2911] section 4.1), rather than the -2 value used in some MIBs [RFC2707] 🌷
this value MUST be reset to 0 for each document in the job and for each document copy 🫠 that's the reset button, babe 🔥
5. Conformance Requirements ✨
okay bestie, this section is the vibe check on who has to do what 💅 Basically, every attribute in this doc is OPTIONAL for a client and/or a Printer to support 🎀, so client and Printer implementers MAY implement any combination of these attributes 🦋
6. IANA Considerations 🌸
This is the paperwork for IANA 📝 The new registrations go into the IPP Registry, and you follow the procedures in RFC 2911 [RFC2911], section 6 💜 Once they're in, they get published at http://www.iana.org/assignments/ipp-registrations ✨
6.1. Attributes
Here are the attributes getting registered 🍓
Job Template attributes: Ref. Section:
sheet-collate (type2 keyword) RFC 3381 3.1
sheet-default (type2 keyword) RFC 3381 3.1
sheet-supported (1setOf type2 keyword) RFC 3381 3.1
Job Description attributes: Ref. Section:
job-collation-type (type2 enum) RFC 3381 4.1
sheet-completed-copy-number (integer(0:MAX)) RFC 3381 4.2
sheet-completed-document-number (integer(0:MAX))RFC 3381 4.3
impressions-completed-current-copy (integer(0:MAX))
RFC 3381 4.46.2. Keyword Attribute Values
This table has the registration info for every keyword-valued attribute in this doc 🧚 Same deal, these get registered following RFC 2911 [RFC2911] section 6.1 🫶
sheet-collate (type2 keyword) RFC 3381 3.1
'uncollated' RFC 3381 3.1
'collated' RFC 3381 3.1
sheet-collate-default (type2 keyword) RFC 3381 3.1
See "sheet-collate" attribute
sheet-collate-supported (1setOf type2 keyword) RFC 3381 3.1
See "sheet-collate" attribute6.3. Enum Attribute Values
Now the enum-valued attributes 🔥 Registered per RFC 2911 [RFC2911] section 6.1, same as before 💅
job-collation-type (type2 enum) RFC 3381 4.1
'1' 'other' RFC 3381 4.1
'2' 'unknown' RFC 3381 4.1
'3' 'uncollated-sheets' RFC 3381 4.1
'4' 'collated-documents' RFC 3381 4.1
'5' 'uncollated-documents' RFC 3381 4.17. Internationalization Considerations 🌈
The IPP extensions in this doc need the same internationalization considerations as any of the Job Template and Job Description attributes defined in IPP/1.1 [RFC2911] 🌍 No new drama here, it's giving consistency 💖
8. Security Considerations 💀
⚠️ Okay bestie, this part is SERIOUS. The IPP extensions defined in this document require the same security considerations as any of the Job Template attributes and Job Description attributes defined in IPP/1.1 [RFC2911]. Don't skip it. Security is not optional, periodt 🔒
9. References 📚
9.1. Normative References
Here are the normative ones you actually need to read 🤓
[RFC2910] Herriot, R., Butler, S., Moore, P. and R. Turner,
"Internet Printing Protocol/1.1: Encoding and Transport",
RFC 2910, September 2000.
[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P.
Powell, "Internet Printing Protocol/1.1: Model and
Semantics", RFC 2911, September 2000.9.2. Informative References
These are the background reads 🦋 Super helpful for the lore
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Turner,
"Internet Printing Protocol/1.0: Encoding and Transport",
RFC 2565, April 1999.
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
Powell, "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2566, April 1999.
[RFC2567] Wright, F.D., "Design Goals for an Internet Printing
Protocol", RFC 2567, April 1999.
[RFC2568] Zilles, S., "Rationale for the Structure and Model and
Protocol for the Internet Printing Protocol", RFC 2568,
April 1999.
[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
"Mapping between LPD and IPP Protocols", RFC 2569, April
1999.
[RFC2707] Bergman, R., Hastings, T., Isaacson, S. and H. Lewis, "PWG
Job Monitoring MIB - V1", RFC 2707, November 1999.
[RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C. and H.
Holst, "Internet Printing Protocol/1.1: Implementor's
Guide", RFC 3196, November 2001.
[ipp-ntfy] Herriot, R., Hastings, T., et. al., "Internet Printing
Protocol (IPP): Event Notification and Subscriptions",
Work in Progress.10. Description of the Base IPP Documents 🎀
The base set of IPP documents includes these 🌸
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the
Internet Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
Mapping between LPD and IPP Protocols [RFC2569]"Design Goals for an Internet Printing Protocol" takes a broad look at distributed printing functionality 👀 It walks through real-life scenarios to figure out what a printing protocol for the Internet actually needs 💅 It covers requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0 [RFC2566, RFC2565]. And a few OPTIONAL operator operations were added to IPP/1.1 [RFC2911, RFC2910] ✨
"Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" is the high-level overview 🧠 It maps out the roadmap for the whole suite of IPP spec documents, and it explains the background and reasoning behind the IETF IPP working group's major decisions 🦋
"Internet Printing Protocol/1.1: Model and Semantics" describes a simplified model made of abstract objects, their attributes, and their operations 💖 The model introduces a Printer and a Job, and a Job supports multiple documents per Job 🍓 It also covers how security, internationalization, and directory issues are handled 🔒
"Internet Printing Protocol/1.1: Encoding and Transport" is the formal mapping of those abstract operations and attributes onto HTTP/1.1 [RFC2616] 🌐 It defines the encoding rules for a new Internet MIME media type called "application/ipp", plus the rules for transporting a message body whose Content-Type is "application/ipp" over HTTP 📦 It also defines the 'ipp' scheme for identifying IPP printers and jobs 🧚
"Internet Printing Protocol/1.1: Implementer's Guide" is for implementers of IPP clients and IPP objects 🛠️ It gives insight and advice to help them understand IPP/1.1 and the stuff that might help when designing their client and/or IPP object implementations 💜 For example, it lays out a typical order of processing requests, including error checking. It also explains the motivation behind some of the specification decisions 🙈
"Mapping between LPD and IPP Protocols" gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations 🖨️
Beyond the base docs, the "Event Notification Specification" document [ipp-ntfy] defines OPTIONAL operations that let a client subscribe to printing related events ⭐ Subscriptions come in two flavours: "Per-Job subscriptions" and "Per-Printer subscriptions", and they're modeled as Subscription objects 👑 There are four other operations for subscription objects: get attributes, get subscriptions, renew a subscription, and cancel a subscription 🌈
11. Authors' Addresses 🦋
Here are the people who wrote this thing, with contact info 💌
Tom Hastings
Xerox Corporation
737 Hawaii St. ESAE 231
El Segundo, CA 90245
Phone: 310-333-6413
Fax: 310-333-5514
EMail: hastings@cp10.es.xerox.com
Harry Lewis
IBM
6300 Diagonal Hwy
Boulder, CO 80301-9191
Phone: (303) 924-5337
EMail: harryl@us.ibm.com
Ron Bergman (Editor)
Hitachi Koki Imaging Solutions
1757 Tapo Canyon Road
Simi Valley, CA 93063-3394
Phone: 805-578-4421
Fax: 805-578-4001
EMail: rbergma@hitachi-hkis.com
IPP Web Page: http://www.pwg.org/ipp/
IPP Mailing List: ipp@pwg.orgTo join the ipp mailing list, send this email 📧 (it's a little picky, so follow it exactly):
1) send it to majordomo@pwg.org
2) leave the subject line blank
3) put the following two lines in the message body:
subscribe ipp
endImplementers of this spec are encouraged to join the IPP Mailing List 🫶 That's where you can chat about clarification issues and review registration proposals for additional attributes and values 💬 Heads up: to reduce spam, the list rejects mail from non-subscribers, so you have to subscribe before you can send a question or comment 🙅♀️
12. Full Copyright Statement 💖
Here's the legal stuff, copied exactly 📜 Read it, bestie, it matters 💅
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement ✨
Funding for the RFC Editor function is currently provided by the Internet Society 🌸 Thank you, Internet Society 🫶
📦 where this page comes from
- ietf: rfc3381 2002-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms