draft-ietf-eai-pop-03 IETF 71 Changes from -02 Updated references - - PowerPoint PPT Presentation

draft ietf eai pop 03
SMART_READER_LITE
LIVE PREVIEW

draft-ietf-eai-pop-03 IETF 71 Changes from -02 Updated references - - PowerPoint PPT Presentation

draft-ietf-eai-pop-03 IETF 71 Changes from -02 Updated references Replaced RET8, LST8, and TOP8 commands Replaced US-ASCII with with a single mode- switch UTF8 command ASCII issued before Added comment to authentication.


slide-1
SLIDE 1

draft-ietf-eai-pop-03

IETF 71

slide-2
SLIDE 2

Changes from -02

  • Updated references
  • Replaced US-ASCII with

ASCII

  • Added comment to

language listing failure example

  • Removed IMAP4

reference

  • Replaced RET8, LST8,

and TOP8 commands with a single mode- switch UTF8 command issued before

  • authentication. This

simplifies the protocol, and allows servers to

  • ptionally down-convert

a cache of the maildrop prior to issuing the +OK response entering TRANSACTION state

slide-3
SLIDE 3

Changes from -02 #2

  • Removed most up-

conversion material

  • Removed definition of

up-conversion

  • Added AUTH command

to list of those affected by UTF8 capability

  • Removed LST8 and

TOP8 capability parameters and commands

  • Removed NO-RETR
  • capability. POP servers

are now unconditionally required to support down-conversion of UTF8-native maildrops

slide-4
SLIDE 4

Changes from -02 #3

  • Added sentence about

modifying authentication code to Security Considerations

  • Deleted references to

RFCs 1341, 1847, 2049, 2183, 3501, 3516, 3490

  • Made eai-downgrade

draft normative and required

slide-5
SLIDE 5

Changes for -04

  • Make eai-downgrade draft informative
  • Rationale: UTF8-capable clients will use

UTF8 mode, so no downconversion needed

  • The only clients that need downcoversion

are those that don’t support UTF8, hence don’t need a normative way to reconstruct the UTF8 message

slide-6
SLIDE 6

Doubts Even Here

  • However, if the client is upgraded in the

future to support UTF8, having a normative and consistent way to reconstruct original UTF8 message (for display/reply) may be helpful