Skip to main content

JavaScript Session Establishment Protocol (JSEP)
draft-uberti-rtcweb-rfc8829bis-05

Revision differences

Document history

Date Rev. By Action
2024-01-26
05 Gunter Van de Velde Request closed, assignment withdrawn: Niclas Comstedt Telechat OPSDIR review
2024-01-26
05 Gunter Van de Velde Closed request for Telechat review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2023-10-10
05 (System) RFC Editor state changed to AUTH48
2023-10-02
05 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2023-09-24
05 Murray Kucherawy Returning to RFC Editor queue.
2023-09-24
05 (System) Removed all action holders (IESG state changed)
2023-09-24
05 Murray Kucherawy IESG state changed to RFC Ed Queue from Waiting for AD Go-Ahead
2023-09-22
05 (System) RFC Editor state changed to EDIT from IESG
2023-09-21
05 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2023-09-21
05 Justin Uberti New version available: draft-uberti-rtcweb-rfc8829bis-05.txt
2023-09-21
05 (System) New version approved
2023-09-21
05 (System) Request for posting confirmation emailed to previous authors: Cullen Jennings , Eric Rescorla , Justin Uberti
2023-09-21
05 Justin Uberti Uploaded new revision
2023-09-21
04 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2023-09-19
04 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-uberti-rtcweb-rfc8829bis-04, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-uberti-rtcweb-rfc8829bis-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

The IANA Functions Operator had previously reviewed draft-uberti-rtcweb-rfc8829bis-02 as well.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist
2023-09-07
04 Cindy Morgan
The following Last Call announcement was sent out (ends 2023-09-21):

From: The IESG
To: IETF-Announce
CC: draft-uberti-rtcweb-rfc8829bis@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org, sean@sn3rd.com, superuser@gmail.com …
The following Last Call announcement was sent out (ends 2023-09-21):

From: The IESG
To: IETF-Announce
CC: draft-uberti-rtcweb-rfc8829bis@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org, sean@sn3rd.com, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Second Last Call:  (JavaScript Session Establishment Protocol (JSEP)) to Proposed Standard

The IESG has received a request to make changes to draft-uberti-rtcweb-
rfc8829bis after the document has made it to the RFC Editor queue.  The
original proposed edit was tiny, but it has blossomed into something
much more substantial.  As a result, a supplementary Last Call on the
aggregate proposed change is being issue before allowing the document
to continue toward publication.

The proposed change and its history can be found at
https://github.com/rtcweb-wg/jsep/pull/1033/files.

The IESG has received a request from the Real-Time Communication in
WEB-browsers WG (rtcweb) to consider the following document: - 'JavaScript
Session Establishment Protocol (JSEP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-09-21. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes the mechanisms for allowing a JavaScript
  application to control the signaling plane of a multimedia session
  via the interface specified in the W3C RTCPeerConnection API and
  discusses how this relates to existing signaling protocols.

  This specification obsoletes RFC 8829.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-uberti-rtcweb-rfc8829bis/



No IPR declarations have been submitted directly on this I-D.




2023-09-07
04 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2023-09-07
04 Cindy Morgan Last call was requested
2023-09-07
04 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2023-09-07
04 Cindy Morgan IESG state changed to Last Call Requested from RFC Ed Queue
2023-09-07
04 Cindy Morgan Last call announcement was changed
2023-09-07
04 Cindy Morgan Last call announcement was generated
2023-05-04
04 (System) RFC Editor state changed to IESG from RFC-EDITOR
2023-04-13
04 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2023-01-26
04 (System) IANA Action state changed to No IANA Actions from In Progress
2023-01-26
04 (System) RFC Editor state changed to EDIT
2023-01-26
04 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2023-01-26
04 (System) Announcement was received by RFC Editor
2023-01-26
04 (System) IANA Action state changed to In Progress
2023-01-26
04 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2023-01-26
04 Cindy Morgan IESG has approved the document
2023-01-26
04 Cindy Morgan Closed "Approve" ballot
2023-01-26
04 Cindy Morgan Ballot approval text was generated
2023-01-26
04 Murray Kucherawy IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2023-01-23
04 (System) Removed all action holders (IESG state changed)
2023-01-23
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2023-01-23
04 Justin Uberti New version available: draft-uberti-rtcweb-rfc8829bis-04.txt
2023-01-23
04 (System) New version approved
2023-01-23
04 (System) Request for posting confirmation emailed to previous authors: Cullen Jennings , Eric Rescorla , Justin Uberti
2023-01-23
04 Justin Uberti Uploaded new revision
2022-12-12
03 Murray Kucherawy IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup
2022-11-07
03 Murray Kucherawy Changed action holders to Eric Rescorla, Cullen Jennings, Justin Uberti
2022-10-24
03 Barry Leiba Closed request for Last Call review by ARTART with state 'Overtaken by Events': Document has finished IESG processing
2022-10-24
03 Barry Leiba Assignment of request for Last Call review by ARTART to Carsten Bormann was marked no-response
2022-10-06
03 (System) Removed all action holders (IESG state changed)
2022-10-06
03 Cindy Morgan IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation
2022-10-06
03 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2022-10-05
03 Paul Wouters
[Ballot comment]
Some minor comments that are likely my misunderstanding of the protocol:

Section 3.5.2.1:

        Implementations MUST be prepared to receive …
[Ballot comment]
Some minor comments that are likely my misunderstanding of the protocol:

Section 3.5.2.1:

        Implementations MUST be prepared to receive objects with some fields
        missing, as mentioned above.

What does it mean to be "prepared"? Is there any guidance to give here ?

Section 5.2.1:

        The  MUST be representable by a 64-bit signed integer,
        and the value MUST be less than 2^63-1.

Why is this a _signed_ integer and not an unsigned integer? What is the meaning of
2^63-1 in a 64 bit signed integer ?


        [...] SHOULD NOT be included.

        [...] MUST NOT be included.

Should these be extended to say "MUST be ignored when received" ? Or is there specific action that should take place that can be specified here?

NITS:

        opaque blobs; that is, the application will not need to read or
        change them.

maybe:

        opaque blobs; that is, the application will not need to parse or
        modify these.

("read" is a little ambiguous, it might need to memcpy (read and write) it,
but not grok it)


we could easily enable -> it could easily enable
2022-10-05
03 Paul Wouters [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters
2022-10-05
03 Warren Kumari
[Ballot comment]
As with many of the other ballots:
1: I don't really understand this protocol but
2: I do like the 'diff's :-)

I'd …
[Ballot comment]
As with many of the other ballots:
1: I don't really understand this protocol but
2: I do like the 'diff's :-)

I'd also like to thank Qin Wu for the [OpsDir review](https://datatracker.ietf.org/doc/review-uberti-rtcweb-rfc8829bis-02-opsdir-lc-wu-2022-03-27/), and also the authors for addressing them (https://github.com/rtcweb-wg/jsep/pull/1025) - from what I can tell (see #1 :-)), this improved the document.
2022-10-05
03 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2022-10-05
03 Zaheduzzaman Sarker
[Ballot comment]
Thanks for the updated specification and finding a way solve the issue with minimal changes.

One comment -

  - if not MUST, …
[Ballot comment]
Thanks for the updated specification and finding a way solve the issue with minimal changes.

One comment -

  - if not MUST, I was at least expecting a normative SHOULD to use the must-bundle policy instead of max-bundle in the following text-
   
    "As a result, "max-bundle" is considered deprecated, and new applications should use the "must-bundle" policy instead."
2022-10-05
03 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2022-10-03
03 Éric Vyncke
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-uberti-rtcweb-rfc8829bis-03
CC @evyncke

Thank you for the work put into this document.

Please find below some …
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-uberti-rtcweb-rfc8829bis-03
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Like John Scudder, with such an easy diff vs. RFC 8829, I have only reviewed the diffs.

Special thanks to Sean Turner for the shepherd's detailed write-up including the WG consensus and the justification of the intended status, the unusual format is sensible for such a minimum -bis.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### I-D name

Like Erik Kline @ekline, I really wonder (and regret) why the I-D name was not updated to become draft-ietf-*, the shepherd explanation does not really satisfy me as at least two ADs are commenting on this I-D name and if is generating more work for the IESG review (checking mailing list & status). Not a big deal but a real annoyance.

### Section 4.1.1

The change from "max-bundle" to "must-bundle" is unclear to me (but I am not an expert in this protocol) and, with an apparently significant change, should there be normative language to ensure transition from 8829 to the -bis ?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
2022-10-03
03 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2022-10-03
03 Robert Wilton
[Ballot comment]
Hi,

Thanks for this easy to review diff.

(1) p 23, sec 4.1.1.  Constructor

  [RFC8829] defined a policy known as …
[Ballot comment]
Hi,

Thanks for this easy to review diff.

(1) p 23, sec 4.1.1.  Constructor

  [RFC8829] defined a policy known as "max-bundle", which, while
  defined identically to the "must-bundle" policy described above, was
  implemented by some implementations according to an earlier, pre-
  standard definition (in which, for example, no "m=" sections were
  marked as bundle-only).  As a result, "max-bundle" is considered
  deprecated, and new applications should use the "must-bundle" policy
  instead.

Disclaimer, I don't know this protocol.

I'm not sure why this isn't 'must use the "must-bundle" policy instead of "max-bundle."'

It is somewhat unclear to me how implementations move from RFC8829 to this RFC.  Specifically, it is unclear, for implementations that follow this RFC rather than RFC8829 (which is being obsoleted by this RFC), what, if any, handling of "max-bundle" is permitted.  My interpretation is that the "max-bundle" policy can still be specified, but its behaviour is not well-defined.  Further, is it appropriate for new implementations to also support "max-bundle" and treat it identically to "must-bundle", or should they reject that policy?

In summary, I think that some extra explanation here might be helpful.

Regards,
Rob
2022-10-03
03 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2022-10-02
03 Erik Kline
[Ballot comment]
# Internet AD comments for {draft-uberti-rtcweb-rfc8829bis-03}
CC @ekline

## Comments

### general

* Is there a reason this didn't get renamed …
[Ballot comment]
# Internet AD comments for {draft-uberti-rtcweb-rfc8829bis-03}
CC @ekline

## Comments

### general

* Is there a reason this didn't get renamed with -ietf-?
  I see a working group adoption event in the history.
  Not important, just curious.

### S5.2.1, S5.3.1

* RFC 8840 Section 4.1.1 says that either 0.0.0.0 or :: may be used.  This
  section says that "c=" MUST use 0.0.0.0.  Can :: be used instead?

* Ditto for the Initial Answers discussion (and 8440 S4.1.3), pp. 53, 55.
2022-10-02
03 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2022-09-30
03 Lars Eggert
[Ballot comment]
# GEN AD review of draft-uberti-rtcweb-rfc8829bis-03

CC @larseggert

Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/i_745aF4T6deyFdN6ocUBuddfg8). …
[Ballot comment]
# GEN AD review of draft-uberti-rtcweb-rfc8829bis-03

CC @larseggert

Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/i_745aF4T6deyFdN6ocUBuddfg8).

## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Reference `[RFC4566]` to `RFC4566`, which was obsoleted by `RFC8866` (this may
be on purpose).

Reference `[RFC5285]` to `RFC5285`, which was obsoleted by `RFC8285` (this may
be on purpose).

Reference `[RFC6347]` to `RFC6347`, which was obsoleted by `RFC9147` (this may
be on purpose).

Reference `[RFC5245]` to `RFC5245`, which was obsoleted by `RFC8445` and
`RFC8839` (this may be on purpose).

Reference `[RFC8843]` to `RFC8843`, which was obsoleted by `RFC9143` (this may
be on purpose).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool
2022-09-30
03 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2022-09-29
03 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2022-09-29
03 Roman Danyliw [Ballot comment]
Thank you to Yaron Sheffer for the SECDIR review.
2022-09-29
03 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2022-09-28
03 John Scudder [Ballot comment]
I really appreciate the clean diff vs 8829. Thanks for an easy review.
2022-09-28
03 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2022-09-28
03 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Niclas Comstedt
2022-09-28
03 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Niclas Comstedt
2022-09-26
03 Cindy Morgan Placed on agenda for telechat - 2022-10-06
2022-09-25
03 Barry Leiba Request for Last Call review by ARTART is assigned to Carsten Bormann
2022-09-25
03 Barry Leiba Request for Last Call review by ARTART is assigned to Carsten Bormann
2022-09-25
03 Barry Leiba Assignment of request for Last Call review by ARTART to Matthew Miller was marked no-response
2022-09-23
03 Murray Kucherawy Ballot has been issued
2022-09-23
03 Murray Kucherawy [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy
2022-09-23
03 Murray Kucherawy Created "Approve" ballot
2022-09-23
03 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2022-09-23
03 Murray Kucherawy IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2022-09-23
03 Murray Kucherawy Ballot writeup was changed
2022-09-21
03 (System) Removed all action holders (IESG state changed)
2022-09-21
03 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-09-21
03 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2022-09-21
03 Justin Uberti New version available: draft-uberti-rtcweb-rfc8829bis-03.txt
2022-09-21
03 (System) New version approved
2022-09-21
03 (System) Request for posting confirmation emailed to previous authors: Cullen Jennings , Eric Rescorla , Justin Uberti
2022-09-21
03 Justin Uberti Uploaded new revision
2022-04-06
02 Murray Kucherawy Changed action holders to Eric Rescorla, Cullen Jennings, Justin Uberti
2022-04-06
02 Murray Kucherawy Comments from OPSDIR and GENART appear to be converging on the idea that there will be some revised text.
2022-04-06
02 (System) Changed action holders to Eric Rescorla, Cullen Jennings, Murray Kucherawy, Justin Uberti (IESG state changed)
2022-04-06
02 Murray Kucherawy IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for Writeup
2022-04-05
02 (System) IESG state changed to Waiting for Writeup from In Last Call
2022-03-27
02 Joel Halpern Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Joel Halpern. Sent review to list.
2022-03-27
02 Qin Wu Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Qin Wu. Sent review to list.
2022-03-19
02 Yaron Sheffer Request for Last Call review by SECDIR Completed: Ready. Reviewer: Yaron Sheffer. Sent review to list.
2022-03-18
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2022-03-18
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2022-03-17
02 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2022-03-17
02 (System)
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-uberti-rtcweb-rfc8829bis-02, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-uberti-rtcweb-rfc8829bis-02, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Michelle Thangtamsatid
IANA Services Specialist
2022-03-17
02 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2022-03-17
02 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2022-03-16
02 Barry Leiba Request for Last Call review by ARTART is assigned to Matthew Miller
2022-03-16
02 Barry Leiba Request for Last Call review by ARTART is assigned to Matthew Miller
2022-03-15
02 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Qin Wu
2022-03-15
02 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Qin Wu
2022-03-15
02 Cindy Morgan IANA Review state changed to IANA - Review Needed
2022-03-15
02 Cindy Morgan
Telnet TN3270 Enhancements Working Group                        B. Kelly
Internet Draft            …
Telnet TN3270 Enhancements Working Group                        B. Kelly
Internet Draft                                        Auburn University
Expiration Date: October 1997                                  May 1997
File name: draft-ietf-tn3270e-ver2-enhance-00.txt

                          TN3270 Enhancements

Status of this Memo

  This document is an Internet-Draft.  Internet-Drafts are working
  documents of the Internet Engineering Task Force (IETF), its
  areas, and its working groups.  Note that other groups may also
  distribute working documents as Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six
  months and may be updated, replaced, or obsoleted by other
  documents at any time.  It is inappropriate to use Internet-
  Drafts as reference material or to cite them other than as
  "work in progress."

  To view the entire list of current Internet-Drafts, please check
  the "1id-abstracts.txt" listing contained in the Internet-Drafts
  Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
  (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
  Coast), or ftp.isi.edu (US West Coast).

Abstract

  This document describes a protocol that more fully supports 3270
  devices than do the existing tn3270 practices.  Specifically, it
  defines a method of emulating both the terminal and printer members
  of the 3270 family of devices via Telnet; it provides for the ability
  of a Telnet client to request that it be assigned a specific device-
  name (also referred to as "LU name" or "network name"); finally, it
  adds support for a variety of functions such as the ATTN key, the
  SYSREQ key, and SNA response handling.

  This protocol is negotiated under the TN3270E Telnet Option, and is
  unrelated to the Telnet 3270 Regime Option as defined in RFC 1041
  [1].

TABLE OF CONTENTS

  1.  Introduction ...............................................  2
  2.  TN3270E OVERVIEW ...........................................  4
  3.  COMMAND NAMES AND CODES ....................................  4
  4.  COMMAND MEANINGS ...........................................  5

Kelly                                                          [Page 1]
Internet Draft            TN3270 Enhancements                  May 1997

  5.  DEFAULT SPECIFICATION ......................................  7
  6.  MOTIVATION .................................................  7
  7.  TN3270E SUB-NEGOTIATION RULES ..............................  7
      7.1  DEVICE-TYPE Negotiation ................................  7
          7.1.1 Device Pools ......................................  8
          7.1.2 CONNECT Command ................................... 10
          7.1.3 ASSOCIATE Command ................................. 10
          7.1.4 Accepting a Request ............................... 11
          7.1.5 REJECT Command .................................... 11
      7.2  FUNCTIONS Negotiation .................................. 12
          7.2.1 Commands .......................................... 12
          7.2.2 List of TN3270E Functions ......................... 13
  8.  TN3270E DATA MESSAGES ...................................... 14
      8.1  The TN3270E Message Header ............................. 15
          8.1.1 DATA-TYPE Field ................................... 15
          8.1.2 REQUEST-FLAG Field ................................ 16
          8.1.3 RESPONSE-FLAG Field ............................... 16
          8.1.4 SEQ-NUMBER Field .................................. 18
  9.  BASIC TN3270E .............................................. 18
      9.1  3270 Mode and NVT Mode ................................. 18
  10. DETAILS OF PROCESSING TN3270E FUNCTIONS .................... 19
      10.1 The SCS-CTL-CODES Function ............................. 19
      10.2 The DATA-STREAM-CTL Function ........................... 20
      10.3 The BIND-IMAGE Function ................................ 21
      10.4 The RESPONSES Function ................................. 22
        10.4.1 Response Messages ................................. 23
      10.5 The SYSREQ Function .................................... 25
        10.5.1 Background ........................................ 25
        10.5.2 TN3270E Implementation of SYSREQ .................. 26
  11. THE 3270 ATTN KEY .......................................... 27
  12. 3270 STRUCTURED FIELDS ..................................... 28
  13. IMPLEMENTATION GUIDELINES .................................. 28
      13.1 3270 Data Stream Notes ................................. 28
      13.2 Negotiation of the TN3270E Telnet Option ............... 28
      13.3 A "Keep-alive" Mechanism ............................... 29
      13.4 Examples ............................................... 29
  14. SECURITY CONSIDERATIONS .................................... 33
  15. REFERENCES ................................................. 33
  16. AUTHOR'S NOTE .............................................. 34
  17. AUTHOR'S ADDRESS ........................................... 34

1.  Introduction

  Currently, support for 3270 terminal emulation over Telnet is
  accomplished by the de facto standard of negotiating three separate
  Telnet Options - Terminal-Type [2], Binary Transmission [3], and End
  of Record [4].  Note that there is no RFC that specifies this
  negotiation as a standard.  RFC 1041 attempted to standardize the
  method of negotiating 3270 terminal support by defining the 3270
  Regime Telnet Option.  Very few developers and vendors ever
  implemented RFC 1041.

Kelly                                                          [Page 2]
Internet Draft            TN3270 Enhancements                  May 1997

  This document will refer to the existing practice of negotiating
  these three Telnet Options before exchanging the 3270 data stream as
  &
2022-03-15
02 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2022-03-15
02 Cindy Morgan Last call announcement was changed
2022-03-15
02 Cindy Morgan Last call announcement was generated
2022-03-14
02 Murray Kucherawy Last call was requested
2022-03-14
02 Murray Kucherawy Ballot approval text was generated
2022-03-14
02 Murray Kucherawy Ballot writeup was generated
2022-03-14
02 Murray Kucherawy IESG state changed to Last Call Requested from AD Evaluation
2022-03-14
02 Murray Kucherawy Last call announcement was generated
2022-03-14
02 Murray Kucherawy IESG state changed to AD Evaluation from Publication Requested
2022-03-09
02 Sean Turner
# Summary

Sean Turner is the document shepherd.
Murray Kucherawy is the responsible Area Director?

This document is a bis for JSEP (aka 8829). The …
# Summary

Sean Turner is the document shepherd.
Murray Kucherawy is the responsible Area Director?

This document is a bis for JSEP (aka 8829). The changes are noted in s1.3.

This I-D is Standards Track because JSEP is Standards Track.

Please note that this is a WG I-D despite the I-D's name; we adopted it as is and did not want to waste time submitting a draft-ietf-rtcweb version.

# Review and Consensus

This I-D was the sole topic of conversation at IETF 110 & 111. It was developed in close coordination with MMUSIC who produced a coordinated bis for RFC 8843, which is now published as RFC 9143.

The Shepherd does not believe there are any controversies. There is consensus as demonstrated during the WGLC that there is consensus to publish this document. I do not believe additional review is required.

# Intellectual Property

The Shepherd has confirmed that each author has stated that to their direct, personal knowledge any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

# Other Points

None.
2022-03-09
02 Sean Turner IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2022-03-09
02 Sean Turner IESG state changed to Publication Requested from AD is watching
2022-03-09
02 Sean Turner
# Summary

Sean Turner is the document shepherd.
Murray Kucherawy is the responsible Area Director?

This document is a bis for JSEP (aka 8829). The …
# Summary

Sean Turner is the document shepherd.
Murray Kucherawy is the responsible Area Director?

This document is a bis for JSEP (aka 8829). The changes are noted in s1.3.

This I-D is Standards Track because JSEP is Standards Track.

Please note that this is a WG I-D despite the I-D's name; we adopted it as is and did not want to waste time submitting a draft-ietf-rtcweb version.

# Review and Consensus

This I-D was the sole topic of conversation at IETF 110 & 111. It was developed in close coordination with MMUSIC who produced a coordinated bis for RFC 8843, which is now published as RFC 9143.

The Shepherd does not believe there are any controversies. There is consensus as demonstrated during the WGLC that there is consensus to publish this document. I do not believe additional review is required.

# Intellectual Property

The Shepherd has confirmed that each author has stated that to their direct, personal knowledge any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

# Other Points

None.
2022-03-04
02 Sean Turner
# DRAFT - DRAFT

# Summary

Sean Turner is the document shepherd.
Murray Kucherawy is the responsible Area Director?

This document is a bis for …
# DRAFT - DRAFT

# Summary

Sean Turner is the document shepherd.
Murray Kucherawy is the responsible Area Director?

This document is a bis for JSEP (aka 8829). The changes are noted in s1.3.

This I-D is Standards Track because JSEP is Standards Track.

Please note that this is a WG I-D despite the I-D's name; we adopted it as is and did not want to waste time submitting a draft-ietf-rtcweb version.

# Review and Consensus

This I-D was the sole topic of conversation at IETF 110 & 111. It was developed in close coordination with MMUSIC who produced a coordinated bis for RFC 8843, which is now published as RFC 9143.

The Shepherd does not believe there are any controversies. There is consensus as demonstrated during the WGLC that there is consensus to publish this document. I do not believe additional review is required.

# Intellectual Property

The Shepherd has confirmed that each author has stated that to their direct, personal knowledge any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

# Other Points

None.

# DRAFT - DRAFT
2022-03-04
02 Sean Turner IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2022-03-04
02 Sean Turner Notification list changed to sean@sn3rd.com because the document shepherd was set
2022-03-04
02 Sean Turner Document shepherd changed to Sean Turner
2022-03-03
02 Justin Uberti New version available: draft-uberti-rtcweb-rfc8829bis-02.txt
2022-03-03
02 (System) New version approved
2022-03-03
02 (System) Request for posting confirmation emailed to previous authors: Cullen Jennings , Eric Rescorla , Justin Uberti
2022-03-03
02 Justin Uberti Uploaded new revision
2021-12-04
01 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2021-12-04
01 Murray Kucherawy Responsible AD changed to Murray Kucherawy
2021-12-04
01 Murray Kucherawy IESG process started in state AD is watching
2021-12-04
01 Murray Kucherawy Changed consensus to Yes from Unknown
2021-12-04
01 Murray Kucherawy Intended Status changed to Proposed Standard from None
2021-10-28
01 Sean Turner IETF WG state changed to In WG Last Call from WG Document
2021-10-25
01 Justin Uberti New version available: draft-uberti-rtcweb-rfc8829bis-01.txt
2021-10-25
01 (System) New version approved
2021-10-25
01 (System) Request for posting confirmation emailed to previous authors: Cullen Jennings , Eric Rescorla , Justin Uberti
2021-10-25
01 Justin Uberti Uploaded new revision
2021-09-19
00 Sean Turner IETF WG state changed to WG Document from Adopted by a WG
2021-09-19
00 Sean Turner IETF WG state changed to Adopted by a WG from Candidate for WG Adoption
2021-09-01
00 Sean Turner IETF WG state changed to Candidate for WG Adoption
2021-09-01
00 Sean Turner Notification list changed to none
2021-09-01
00 Sean Turner Changed group to Real-Time Communication in WEB-browsers (RTCWEB)
2021-09-01
00 Sean Turner Changed stream to IETF
2021-07-10
00 Justin Uberti New version available: draft-uberti-rtcweb-rfc8829bis-00.txt
2021-07-10
00 (System) New version approved
2021-07-10
00 Justin Uberti Request for posting confirmation emailed  to submitter and authors: Cullen Jennings , Eric Rescorla , Justin Uberti
2021-07-10
00 Justin Uberti Uploaded new revision