Browse Prior Art Database

The application/whoispp-response Content-type (RFC2958)

IP.com Disclosure Number: IPCOM000005151D
Original Publication Date: 2000-Oct-01
Included in the Prior Art Database: 2019-Feb-12
Document File: 6 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

L. Daigle: AUTHOR [+1]

Related Documents

10.17487/RFC2958: DOI

Abstract

The intention of this document, in conjunction with RFC 2957, is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions. This memo provides information for the Internet community.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 41% of the total text.

Network Working Group L. Daigle Request for Comments: 2958 Thinking Cat Enterprises Category: Informational P. Faltstrom Cisco Systems Inc. October 2000

The application/whoispp-response Content-type

Status of this Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

This document defines the expression of Whois++ protocol (RFC1835) responses within MIME (Multipurpose Internet Mail Extensions) (RFC2046) media types. The intention of this document, in conjunction with RFC 2957 is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions.

1. MIME Registration Information

To: iana@isi.edu Subject: Registration of MIME media type application/whoispp-response

MIME Type name: Application

MIME subtype name: whoispp-response

Required parameters: none

Optional parameters: none

Encoding considerations: Any valid MIME encodings may be used

Security considerations: This content-type contains purely descriptive information (i.e., no directives). There are security considerations with regards to the appropriateness (privacy) of

Daigle & Faltstrom Informational [Page 1]

RFC 2958 application/whoispp-response Content-Type October 2000

information provided through the use of this content-type, and the authenticity of the information so-provided. This content-type provides no native mechanisms for authentication.

Published specification: this document

Person & email address to contact for further information:

Leslie L. Daigle leslie@thinkingcat.com

Intended usage: common

2. whoispp-response Syntax

The following grammar, which uses ABNF-like notation as defined in [RFC2234], defines a subset of responses expected from a Whois++ server upon receipt of a valid Whois++ query. As such, it describes the expected structure of a whoispp-response media type object.

N.B.: As outlined in the ABNF definition, rule names and string literals are in the US-ASCII character set, and are case-insensitive.

server = goodmessage mnl output mnl endmessage nl / badmessage nl endmessage nl

output = full / abridged / summary / handle

full = 0*(full-record / server-to-ask)

abridged = 0*(abridged-record / server-to-ask)

summary = summary-record

handle = 0*(handle-record / server-to-ask)

full-record = "# FULL " template serverhandle localhandle system-nl 1*(fulldata system-nl) "# END" system-nl

abridged-record = "# ABRIDGED " template serverhandle localhandle system-nl abridgeddata "# END" system-nl

Daigle & Faltstrom Informational [Page 2]

RFC 2958 application/whoispp-response Content-Type October 2000

summary-record = "# SUMMARY " serverhandle system-nl summarydata "# END" system-nl

handle-record = "# HANDLE " template serverhandle localhandle system-nl

server-to-ask = "# SERVER-TO-ASK " serverhandle system-nl server-to-askdata "# END" s...

Processing...
Loading...