2016-04-04 17:46:08-0300 ------------------------ Notes for HRPC meeting at IETF 95 Chaired by Niels and Avri dkg: notetaker olaf: jabber scribe Initial presentation/administrivia by Niels Ramsey Nasser presents: http://nas.sr/ @ra http://nas.sr/%D9%82%D9%84%D8%A8/ "Text is hard, assumptions are everywhere" ---- Chris Newman RFC 2277, written in 1997/1998 has a requirement: you must support UTF-8. I suspect that spec needs an update, we could use non-european eyes on it. Ramsey: how do we deal with this in protocols? Andrew Sullivan: you're right, there is a cultural bias baked into these protocols. And you're absolutely right that text is really hard. i disagree that programming languages are "in english"; they do come from a particular linguistic culture, but i want to be careful about stepping from there to "in a language". We make our tools, and our tools make us. There are facts in the world that we can't do anything about. If we want to do i18n of protocols, etc, then we have tons more work to do the translation -- possibly more than it took us to build what we have in the first place. There are engineering tradeoffs involved. We have a real problem with i18n at the IETF for two reasons: * we "don't do user interface", but lots of things from protocols leak up into user interface, but many of our assumptions are broken. * we don't have enough people who understand the problems and can help to fix them within the IETF. For example, we need people who understand the difference between "language" and "script" I have an update for 2277 rotting on my hard drive, it's really tough. Ramsey: I understand the engineering challenges, but i don't think they're mutually exclusive. On the one hand, they are arbitrary strings, but there is a real advantage for people who can natively interpret or easily internalize those strings. Sean Leonard: how many of the problems that you've identified are Internet protocols, and how many are more systems-level questions? Because a lot of Internet work inherited from these stuff, maybe that's something that we should bring to those places. Ramsey: Yes, clearly this isn't just an IETF issue. I ran into IETF questions for قلب because i tried to write an HTTP library for it, and i realized i couldn't do that natively in قلب. mnot: I agree that this is unfair. For HTTP, syntactically, field names are ascii, and field values are a bucket of octets (except for newlines). I don't think you can change the field name rules at this time. For interoperability, we need to support the deployed base; for new protocols, that's where it gets really interesting. We tried to provide UTF-8 protocol elements with Atom, and ran into tons of problems. but in W3C, we're very close to being able to write 100% arabic html, without a lick of english in it. Ramsey: I'm not claiming i have a way to produce them that would be readable; i don't want them to be arabic! I think this is a huge unknown problem. mnot: Right; i also don't know what to do, but i feel like if you want a private http header you ought to be able to make it in whatever language you want. For protocol-specific questions, i think the low-hanging fruit might be in building better tooling. ------------ Nick Doty presents https://npdoty.name https://ctsp.berkeley.edu Christine Runnegar: As co-chair of W3C PING, thanks to Nick for the work he's done. I'm interested in how we can get more expertise so that we can get more reviews of this kind of work. If anyone has web standards expertise and wants to help review, please come find me. ------------- Corinne Cath presents Roland Bless: About the literature: we were a little bit misinterpreted -- maybe it's not desirable to implement or hardcode human rights into protocols, but some design decisions may put implicit restrictions on certain human rights. Our main point was to create an awareness for that. The direction of posing questions is a good way to go, but the current draft suggests that we have a position that isn't true. we have another document coming up too. Corinne: thanks, happy to adjust the draft to reflect your point. mnot: i'm working on the security/privacy questionnaire in W3C. Maybe an opportunity to share? we'd be happy to have collaboration there. You mentioned that protocols should be stateless -- this is potentially really problematic, and i don't want it misrepresented, because some engineers might reject the document out of hand because of it. a CDN is an agent of the origin server. there are many parties involved. who should get to know? is something on amazon? does it matter that it was on a Dell computer? this seems like a rabbit hole. But CDNs also are really interested in ways that they can prove that they didn't touch the bytes. Giovane Moura: MAPRG is building a lab on middleboxes; if you want more data, you should talk to Paul Hoffman and others there. ------------- Niels asks: who has hrpc-relevant drafts in the pipeline? Two hands raised (Giovane and Shane, i think?) ------------- Avri Doria presents work on the latest draft, calls for readers, editors, and contributors to document the work going on at hrpc. ------------- Joe Hall presents. Olaf channels Nick: Do you have enough academics providing feedback on the attacks you have seen? Joe: There are folks who i would love to rope in, but haven't gotten to: KU Leuven, Citizen Lab, etc. but i'd also like non-academics. industry, network operators, etc would all have great inputs. There's a tendency for academics to talk about attacks we haven't seen in the field -- i don't want to exclude those, but we're looking more for things that are active in the field. Alyssa Cooper: Maybe we could get specific to commit to a review at a specific protocol level. for example, mnot might be willing to look at the HTTP bits, like you have Stephane looking at the DNS bits. If you want application layer people, i can help some with that. -------------