1 / 10

NFSv4 Internationalization Status

NFSv4 Internationalization Status. David Noveck Nfsv4 Working Group meeting at IETF88 November 5, 2013. Overview. History of NFSv4 internationalization RFC3010 and RFC3010bis drafts RFC3050 and stringprep Initial (failed) attempt to de-stringprep-ize in RFC3530bis

derex
Télécharger la présentation

NFSv4 Internationalization Status

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NFSv4 Internationalization Status David Noveck Nfsv4 Working Group meeting at IETF88 November 5, 2013

  2. Overview • History of NFSv4 internationalization • RFC3010 and RFC3010bis drafts • RFC3050 and stringprep • Initial (failed) attempt to de-stringprep-ize in RFC3530bis • NFSv4 internationalization’s current status • Current I18N in RFC3530bis • Process going forward • Handling NFSv4 Internationalization in future • With précision , it is hoped

  3. How did we get here?(before rfc3530bis-04) • Were supposed to do I18N • Didn’t think we could really do that • Wrote a lot of MUST’s and then ignored them • That “worked” during RFC3010 and thru rfc3010bis-03 • With rcf3010bis-04 and RFC3530: • Spec was stringprep-ed (IESG insisted) • Had lots more MUST’s to ignore • Many were in normatively referenced documents that people didn’t read. • We had implementations that worked • But the spec had only the most tenuous connection with the reality of the implementation environment • Things left as-is through rfc3530bis-03 (March 2010)

  4. How did we get here?(from rfc3530bis-04 onward) • Rewrote chapter in -04 (July 2010) • Tried to eliminate all cases in which spec told implementers to do something impossible • While staying as close to stringprep as possible • Continued that approach until -26 (August 2013) • Working group continued to refine text • Then IESG said “No Way” • Brief summary of IESG issues • Too complex • Too much freedom for different client/server behaviors • No workable way for parties to find out about each others i18n characteristics

  5. Current i18N in rfc3530bis • Goal is to describe what is actually implemented • Based on pre-stringprep text • from rfc3010bis-03 • Adjusted, as necessary, to reflect actual implementations • In current drafts: • draft-ietf-nfsv4-rfc3530bis-28 (chapter 12) • draft-ietf-nfsv4-rfc3530bis-19 (string-related typedefs)

  6. Need Your (and Others’) Input! • Please read docs and comment • SCREAM, if implementations conflict with a MUST • Would help to know about how implementations deal with SHOULDs and MAYs • Also need input from implementers not here • And from those that don’t read the nfsv4 list • Of particular interest: • Are there things here that IESG will have trouble with? • File systems that do normalization-related processing • We have info about ZFS, but not HFS+ • Are there others ?

  7. Going forward with rfc3530bis • It seems Sisyphean • I’m pretty sure Tom thinks so • Started in 2009 and i18n now seems to be the only remaining issue • If the working group and Martin is OK with i18n as it is now, should present to the IESG • Job for Martin and a player to be named later • David Black has volunteered • Spencer is current designee • Please give them help if they ask for it.

  8. I18N issues beyond NFSv4.0 • Minor versions beyond v4.0 • V4.1: i18n in RFC5661 same as RFC3530 • Doesn’t match implementations • V4.2: i18n inherited from v4.1 • Also may be an issue for related protocols • e.g. FEDFS Admin protocol inherits pathname description from RFC5661

  9. NFSv4 I18N issues and Précis • Need to adapt to précis • IESG wants it (and may insist) • Seems more rational/limited than stringprep • Issues to resolve with précis • Limitations on what we can standardize • Our normalization-related requirements • May have to teach people about normalization-insensitive LOOKUPs

  10. New i18n Document for NFSv4 • We need a new I18n document for NFSv4 • Should address all minor versions • May need some additional/preparatory documents • Should be as compatible with précis as we can make it and still be implementable. • Troublesome issues: • Files in existing FS’s with non-UTF8 names • Clients unaware of encoding

More Related