RFC 2503

MIME Types for Use with the ISO ILL Protocol 🎀

okay bestie, this is RFC 2503 📚 from the Network Working Group. It's marked Informational 💅, so it's giving "here's some info," not a standard ✨. It's dated February 1999 🦋 and written by R. Moulton (United Kingdom) and M. Needleman (Data Research Associates, Inc) 🌸. The title block doesn't list anything it obsoletes or updates.

---

Status of This Memo ✨

This memo gives information to the Internet community 🫶. It does not specify an Internet standard of any kind, and it can be shared with no limits 🌈.

Copyright Notice 💜

Copyright (C) The Internet Society (1999). All rights reserved 🔒.

Abstract 🌸

okay so this memo describes a set of MIME types for use with the ISO Interlibrary Loan Protocol (ISO 10160/10161) 📖. There are two MIME types in here 👯‍♀️.

The first one is a media type for carrying objects that are BER [BER] encoded ISO ILL Protocol Data Units (PDUs) 🧚. BER is the basic set of Encoding Rules used to encode PDUs that have been described with ASN.1 (Abstract Syntax Notation 1) [ASN.1] 💖.

The second one is for the associated document delivery instructions 🦋. Document Delivery Instructions (DDI) is an emerging protocol that enables automatic electronic delivery of items ✨. A request management system (which might have received a request for an item through the ISO Interlibrary Loan Protocol (ISO 10160/10161)) can pass the details of the request, the item, and the delivery over to a delivery module 🍓. It can also get reports back about the delivery process or about the item's arrival 📬. DDI is currently being submitted to the ISO TC46/SC4/WG4 committee for approval as an ISO standard 🔥.

Registration Information 🎀

These are the two media types being registered, and they're giving very organized energy 💅.

application/iso-10161-ill-1 and application/ill-ddi 💖

Media type name: application
Media subtype name:  iso-10161-ill-1 - for BER encoded ISO ILL APDU's

Media type name:  application
Media subtype name:  ill-ddi - For associated Document Delivery
                     Instructions

Required Parameter: transfer-encoding 🔑

For BER-encoded PDUs or DDIs, the only current legal value of this parameter is:

iso-8825-ber

So transfer-encoding describes how the PDU was encoded before it got submitted to the transport service (in this case MIME/RFC822) 🚀. Both protocols in this RFC specify their APDUs using ASN.1 (ISO 8824:1990), and the most common way to encode ASN.1 packets is the Basic Encoding Rules (BER ISO 8825) 🧠.

This parameter is included so these MIME types can be used with other encoding schemes in the future 🔮. For example, ISO 10161 also describes an encoding method using EDIFACT 🌷. Other schemes might show up later too 🦋. (EDIFACT isn't currently in use among the ISO 10161 and DDI communities, so a value for transfer-encoding that describes it isn't being registered in this RFC 🙈.)

Optional parameter: iso-10161-apdu-type ✨

Valid values are:

ILL-Request
Forward-Notification
Shipped
ILL-Answer
Conditional-Reply
Cancel
Cancel-Reply
Received
Recall
Returned
Checked-In
Overdue
Renew
Renew-Answer
Lost
Damaged
Message
Status-Query
Status-Or-Error-Report
Expired

This parameter is optional, and you can include it for informational or diagnostic purposes 🧁. The type of the PDU or DDI can be figured out from the actual data that gets sent 🔍. The use and format of PDUs and DDIs are defined in the relevant protocol documents that describe them 📚.

Examples 💫

Here's what the headers look like in action 👀:

Content-Type: application/iso-10161-ill-1;  transfer-encoding=iso-
8825-ber; iso-10161-apdu-type=Recall;

Content-Type: application/ill-ddi;  transfer-encoding=iso-8825-ber;

Encoding 🫧

BER-encoded material is binary in nature 🤖. So when 7bit or 8bit transport mechanisms are used, some form of encoding is needed 🧃.

The recommended encoding for BER-encoded PDUs is Base64 💜.

PDUs per Message 📮

When you're sending BER-encoded PDUs or DDIs, each MIME body part carries at most one BER-encoded PDU or DDI 💅. But a single MIME message with multiple body parts can transport more than one BER PDU and/or DDI 🍓. Main character energy for sure 👑.

Security Considerations 🔐

ngl, this section is serious. There are no known security risks associated with transmitting BER-encoded PDUs in general 🙏. However, a particular BER-encoded PDU or DDI may have security considerations that make it inappropriate to send through public data networks, unless appropriate protection mechanisms (like encryption) are used 💀. This could happen, for example, when organizations are exchanging documents that contain secure or classified information, and it's necessary to keep information about both the material being exchanged and the exchanging partners confidential 🔒.

Interoperability Considerations 🧚‍♀️

BER is an international standard for encoding data that's meant to be transferred between two systems that might store data in different local formats internally [BER] ✨. So it's basically the universal translator 🌈.

References 📚

• [BER] ISO/IEC 8825:1990 Information Technology - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)
• [ASN.1] ISO/IEC 8824:1990 Information Technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)
• ISO 10160:1997 Information and Documentation - Open Systems Interconnection - Interlibrary Loan Application Service Definition
• ISO 10161-1:1997 Information and Documentation - Open Systems Interconnection - Interlibrary Loan Application Protocol Specification - Part 1: Protocol Specification

Additional Information 🌷

The National Library of Canada has been designated the maintenance agency for the ISO ILL protocol 🇨🇦. If you want more info on this MIME type, contact:

Barbara Shuh
Library Network Specialist
Information Analysis and Standards
Information and Technology Services
National Library of Canada
395 Wellington Street
Ottawa, Ontario CANADA
K1A 0N4

Phone: (819) 994-6969
Fax:   (819) 994-6835
EMail: barbara.shuh@nlc-bnc.ca

Authors' Addresses 🎀

Ruth Moulton
Consultant
65 Tetherdown
London N10 1NH
United Kingdom

Phone: +44 (181) 883 5823
EMail: ruth@muswell.demon.co.uk


Mark H Needleman
Data Research Associates, Inc.
1276 North Warson Road
P.O. Box 8495
St Louis, MO 63132-1806
USA

Phone: (80)0 325-0888 (US/Canada)
       (314) 432-1100 x318
Fax:   (314) 993-8927
Email: mneedleman@dra.com

Full Copyright Statement 💜

Copyright (C) The Internet Society (1999). All rights reserved 🌈.

You can copy this document and hand it out to others, and you can make derivative works that comment on or explain it, or that help people implement it 💖. You can prepare, copy, publish, and distribute those, in whole or in part, with no restriction of any kind 🦋. The only condition is that the above copyright notice and this paragraph are included on all of those copies and derivative works ✨. But this document itself may not be modified in any way, like by removing the copyright notice or the references to the Internet Society or other Internet organizations 🙅‍♀️. The exception is when it's needed for developing Internet standards, in which case the copyright procedures defined in the Internet Standards process must be followed 📜. Translating it into languages other than English is also allowed 🌸.

The permissions above are perpetual, and the Internet Society or its successors or assigns won't revoke them 💫.

This document and the information in it are 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 💅.