⌕ Поиск по атласу

IETF · RFC · RFC4095

RFC4095 · Attaching Meaning to Solicitation Class Keywords

Attaching Meaning to Solicitation Class Keywords

This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, the No Soliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as "org.example.adv". These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new \%"No-Solicit:" header, which can contain one or more solicitation class keywords inserted by the sender. This document specifies an application based on the Dynamic Delegation Discovery System (DDDS) described in RFC 3401 and related documents. An algorithm is specified to associate a solicitation class keyword with a URI which contains further information about the meaning and usage of that solicitation class keyword. For example, the registrant of the "example.org" domain could use this mechanism to create a URI which contains detailed information about the "org.example.adv" solicitation class keyword. [STANDARDS-TRACK]

Официальная английская аннотация

This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, the No Soliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as "org.example.adv". These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new \%"No-Solicit:" header, which can contain one or more solicitation class keywords inserted by the sender. This document specifies an application based on the Dynamic Delegation Discovery System (DDDS) described in RFC 3401 and related documents. An algorithm is specified to associate a solicitation class keyword with a URI which contains further information about the meaning and usage of that solicitation class keyword. For example, the registrant of the "example.org" domain could use this mechanism to create a URI which contains detailed information about the "org.example.adv" solicitation class keyword. [STANDARDS-TRACK]

Связи документа

Официальный источник · 2005-05-01

Полные импортированные сведения карточки
{
  "id": "RFC4095",
  "number": 4095,
  "title_en": "Attaching Meaning to Solicitation Class Keywords",
  "title_ru": "",
  "summary_ru": "",
  "purpose_ru": "",
  "use_ru": "",
  "full_translation_path": "",
  "full_translation_checked_at": "",
  "full_translation_source_sha256": "",
  "architect_note_ru": "",
  "topics_ru": [],
  "translation_state": "not_prepared",
  "verification_level": "not_prepared",
  "verification_level_ru": "Русская выжимка не подготовлена",
  "verification_note_ru": "",
  "abstract_en": "This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, the No Soliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as \"org.example.adv\". These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new \\%\"No-Solicit:\" header, which can contain one or more solicitation class keywords inserted by the sender. This document specifies an application based on the Dynamic Delegation Discovery System (DDDS) described in RFC 3401 and related documents. An algorithm is specified to associate a solicitation class keyword with a URI which contains further information about the meaning and usage of that solicitation class keyword. For example, the registrant of the \"example.org\" domain could use this mechanism to create a URI which contains detailed information about the \"org.example.adv\" solicitation class keyword. [STANDARDS-TRACK]",
  "authors": [
    "C. Malamud"
  ],
  "organizations": [],
  "publication_date": "2005-05-01",
  "current_status": "PROPOSED STANDARD",
  "current_status_ru": "Предлагаемый стандарт",
  "publication_status": "PROPOSED STANDARD",
  "publication_status_ru": "Предлагаемый стандарт",
  "lifecycle": "active",
  "lifecycle_ru": "Действующий",
  "stream": "IETF",
  "stream_ru": "IETF",
  "area": "",
  "area_ru": "",
  "working_group": "NON WORKING GROUP",
  "source_draft": "draft-malamud-keyword-discovery-05",
  "page_count": 11,
  "doi": "10.17487/RFC4095",
  "keywords": [
    "uri",
    "uniform resource identifier",
    "no soliciting smtp service extension",
    "esmtp service extension",
    "dynamic delegation discovery system",
    "ddds",
    "no-solicit"
  ],
  "formats": [
    "TXT",
    "HTML"
  ],
  "relations": {
    "obsoletes": [],
    "obsoleted_by": [],
    "updates": [],
    "updated_by": [],
    "is_also": [],
    "see_also": []
  },
  "links": {
    "info": "https://www.rfc-editor.org/info/rfc4095/",
    "html": "https://www.rfc-editor.org/rfc/rfc4095.html",
    "txt": "https://www.rfc-editor.org/rfc/rfc4095.txt",
    "datatracker": "https://datatracker.ietf.org/doc/rfc4095/"
  }
}