Seeking input UA-readiness of Open Source Code
Hello UASG colleagues, The measurement wg is working on defining a SOW to assess the UA-readiness of Open-Source Code. This project would be deemed a pilot or alpha version before scaling it for broader reach. Google Doc URL: https://docs.google.com/document/d/1J3ahTuH_1_CzaPfGlNsLLitqhT0AUgATZQymEOVH... The pilot is suggested to look at applications available in Github using Python. We are seeking your input to enrich the scope of work of the pilot and/or correct anything that we may have missed. Please comment or suggest edits directly to the Google Doc (link above). We would like your input by next Tuesday 9/3. Thank you, Dennis, on behalf the Measurement WG
On Friday 30 August 2019 15:15:33 CEST, Tan Tanaka, Dennis via UA-EAI wrote:
Hello UASG colleagues,
The measurement wg is working on defining a SOW to assess the UA-readiness of Open-Source Code. This project would be deemed a pilot or alpha version before scaling it for broader reach. ... The pilot is suggested to look at applications available in Github using Python.
Hm. How do you want to find, classify and test Python code that has been updated to support EAI, but contains no relevant code? I ask because that's a reasonable case for Python. Python software uses third-party packages a great deal, and I have actually seen python software get EAI support merely by changing to a new version of a pip dependency. The googledoc also mentions java, where the same is the case. In the case of java the dependency chains can be quite complex, even more so than for python. (Would a deteiled example help to consider the question?) Arnt
In article <8189de5a-3f0e-44ab-8a91-c4a41c4a404a@gulbrandsen.priv.no> you write:
Hm. How do you want to find, classify and test Python code that has been updated to support EAI, but contains no relevant code?
I ask because that's a reasonable case for Python. Python software uses third-party packages a great deal, and I have actually seen python software get EAI support merely by changing to a new version of a pip dependency.
I'd think that'd apply to perl, ruby, C++, and any other language where programmers use a lot of external libraries. These days that's all of them. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
On 9/1/2019 7:41 AM, John Levine wrote:
In article <8189de5a-3f0e-44ab-8a91-c4a41c4a404a@gulbrandsen.priv.no> you write:
Hm. How do you want to find, classify and test Python code that has been updated to support EAI, but contains no relevant code?
I ask because that's a reasonable case for Python. Python software uses third-party packages a great deal, and I have actually seen python software get EAI support merely by changing to a new version of a pip dependency. I'd think that'd apply to perl, ruby, C++, and any other language where programmers use a lot of external libraries. These days that's all of them.
Code that cleanly relies on external packages to handle EAI would be in its own category, compared to code that actively supports or limits them. For the latter, you might be able to evaluate whether the limitation is deliberate (design) or accidental (bug). The challenge might be to define a signature to scan for for the first category to determine whether its a conduit for EAI. Are there API calls that would be indicative? A./
On Sunday 1 September 2019 19:34:59 CEST, Asmus Freytag wrote:
The challenge might be to define a signature to scan for for the first category to determine whether its a conduit for EAI. Are there API calls that would be indicative?
No. EAI is designed such that APIs tend to need no changes. This is on purpose. For example, a java app that supports email object may use a validation class called 'Email'. If the framework version is new enough to support EAI, then the app's Email objects perform a somewhat different validation than if not. The app itself doesn't really notice any difference (the Email class is framework-provided, it's not in the app). No difference, that is, except that the developers likely haven't tested with EAI addresses. The second commandment of my religion is "that which hasn't been tested yet doesn't work yet". There always is some spoilsport detail. Arnt
On 9/1/2019 2:07 PM, Arnt Gulbrandsen wrote:
On Sunday 1 September 2019 19:34:59 CEST, Asmus Freytag wrote:
The challenge might be to define a signature to scan for for the first category to determine whether its a conduit for EAI. Are there API calls that would be indicative?
No. EAI is designed such that APIs tend to need no changes. This is on purpose. For example, a java app that supports email object may use a validation class called 'Email'. If the framework version is new enough to support EAI, then the app's Email objects perform a somewhat different validation than if not. The app itself doesn't really notice any difference (the Email class is framework-provided, it's not in the app).
No difference, that is, except that the developers likely haven't tested with EAI addresses. The second commandment of my religion is "that which hasn't been tested yet doesn't work yet". There always is some spoilsport detail.
So, you would scan such code projects for references to such an E-mail class and then see whether the code manipulates the inputs/outputs in a way that would break EAIs. Or, alternatively, whether the code just serves as neutral conduit. That amounts to "testing by inspection" and I'm not sure it can be carried out in a useful way; it seems fundamentally not too different from checking whether code is utf-8 safe by looking at how it interacts with string classes. A./
In article <46afdf29-f7fd-4e71-9947-fe3a5941eb2e@gulbrandsen.priv.no> you write:
No. EAI is designed such that APIs tend to need no changes.
That's a rather debatable assertion. I suppose it might be so in a world where everyone supports EAI, or in a trivial application that sends one message to one address, but in this world where we will have a mix of EAI and ASCII mail for the forseeable future, EAI software will have to deal with failures that ASCII mail doesn't. Even with one message to one address, applications will see new errors if they send an EAI message to an ASCII address that happens not to support EAI. R's, John
On 2019/09/02 16:08, John Levine wrote:
In article <46afdf29-f7fd-4e71-9947-fe3a5941eb2e@gulbrandsen.priv.no> you write:
No. EAI is designed such that APIs tend to need no changes.
That's a rather debatable assertion. I suppose it might be so in a world where everyone supports EAI, or in a trivial application that sends one message to one address, but in this world where we will have a mix of EAI and ASCII mail for the forseeable future, EAI software will have to deal with failures that ASCII mail doesn't.
Even with one message to one address, applications will see new errors if they send an EAI message to an ASCII address that happens not to support EAI.
I wanted to write virtually the same thing, but John was faster. Also, I agree with others that limiting the pilot to a specific programming language (Python) isn't such a good idea. Regards, Martin.
On Monday 2 September 2019 09:08:25 CEST, John Levine wrote:
In article <46afdf29-f7fd-4e71-9947-fe3a5941eb2e@gulbrandsen.priv.no> you write:
No. EAI is designed such that APIs tend to need no changes.
That's a rather debatable assertion.
At risk of digressing further, could you give some counterexample? It was easy to find counterexamples during the draft stage, but I brought them up and they were quickly resolved. I didn't need to argue.
I suppose it might be so in a world where everyone supports EAI, or in a trivial application that sends one message to one address, but in this world where we will have a mix of EAI and ASCII mail for the forseeable future, EAI software will have to deal with failures that ASCII mail doesn't.
That's a nice general statement with which I cannot possibly disagree.
Even with one message to one address, applications will see new errors if they send an EAI message to an ASCII address that happens not to support EAI.
What does that mean for APIs? I have reviewed three opensource libraries with EAI support (one each for python, java and c++). None of the three add new errors to their API, and that is quite appropriate in each case, given the scope of what these libraries do and don't. For example, I mentioned a java class yesterday, one for email address validitation. That class doesn't go into detail. Applications that use that class can distinguish syntactically valid email addresses from other strings, and that's all. That's the entire API. Since it doesn't provide a list of possible errors, there's no list to be extended and apps that use this class cannot possibly handle any new EAI-related error cases. You say they "will have to". No. as far as these apps are concerned, the only error case is "invalid address", and if the internal details of that has changed, then these apps do not notice that. Which brings me back to my original point. Perhaps I should elaborate on that, give an example... The original python software I found was something to accept email into a webapp (a calendar thing, actually). Users would be able to send email to a specific address, and the webapp would create/update calendar entries. This was solved using two separate pieces of software: One that accepts email via SMTP, and another that interprets messages as they arrive and reacts to calendar-related attachments. Finding and classifying the first is simple. How does this survey mean to find and classify the second? (Ignoring it is a valid answer, of course.) Arnt
No. EAI is designed such that APIs tend to need no changes. That's a rather debatable assertion.
What does that mean for APIs?
Look at the python smtp client module. It does EAI and has a new SMTPNotSupportedError which is thrown if you send an EAI message and the server at the other end doesn't advertise SMTPUTF8. The smtpd module, an SMTP server, does EAI, and has a new enable_SMTPUTF8 option. It's deprecated in favor of the thready aiosmtpd which also has a similar option. The the email module which does header and MIME parsing and deparsing has an email.policy submodule with a utf8 option that says whether to put unencoded UTF-8 into headers or to MIME encode it. There's doubtless more but that's what I found in a few minutes by searching the docs for SMTPUTF8.
This was solved using two separate pieces of software: One that accepts email via SMTP, and another that interprets messages as they arrive and reacts to calendar-related attachments.
Finding and classifying the first is simple. How does this survey mean to find and classify the second? (Ignoring it is a valid answer, of course.)
I'd guess it'd be like the smtp module, you'd want an option to tell it to accept EAI mail. How you check for that other than by a lot of code examination and test messages is a good question. Regards, John Levine, john.levine@standcore.com Standcore LLC
On Monday 2 September 2019 15:19:03 CEST, John Levine wrote:
... That's a rather debatable assertion. ...
What does that mean for APIs?
Look at the python smtp client module. It does EAI and has a new SMTPNotSupportedError which is thrown if you send an EAI message and the server at the other end doesn't advertise SMTPUTF8.
I looked, and SMTPNotSupportedError isn't EAI-specific. Adding EAI support to a python app doesn't require it, because it was already required.
The smtpd module, an SMTP server, does EAI, and has a new enable_SMTPUTF8 option. It's deprecated in favor of the thready aiosmtpd which also has a similar option.
I looked at it too, and if an application does nothing, it silently gets EAI support. Software will have to handle new errors, you said. There's no new error here and nothing the software actually will have to do. Software that upgrades to require aiosmtpd 3.7 gets EAI support with no change.
The the email module which does header and MIME parsing and deparsing has an email.policy submodule with a utf8 option that says whether to put unencoded UTF-8 into headers or to MIME encode it.
Yes. Still no new error handling required, still no new code path required of apps that use it. If an app doesn't add anything special, the users simply get generic error messages. "Unknown error while sending", "unable to send to <address>", that kind of thing. Arnt
Perhaps the survey ought to have a class between yes and no. Something like "using EAI addresses works when everything works, but the error messages aren't helpful when something fails". I personally don't care. In my opinion there are only two things that matter at this point: "works when it works" and "doesn't break any old functionality". Anything else is a fringe benefit. Arnt
On Mon, 2 Sep 2019, Arnt Gulbrandsen wrote:
What does that mean for APIs?
Look at the python smtp client module. It does EAI and has a new SMTPNotSupportedError which is thrown if you send an EAI message and the server at the other end doesn't advertise SMTPUTF8.
I looked, and SMTPNotSupportedError isn't EAI-specific. Adding EAI support to a python app doesn't require it, because it was already required.
EAI raises that error in routines that never raised it before. I'd say that's an API change.
The smtpd module, an SMTP server, does EAI, and has a new enable_SMTPUTF8 option. It's deprecated in favor of the thready aiosmtpd which also has a similar option.
I looked at it too, and if an application does nothing, it silently gets EAI support.
I looked at it, and if you don't say enable_SMTPUTF8=True it doesn't advertise SMTPUTF8 and you don't get EAI support. Look again.
The the email module which does header and MIME parsing and deparsing has an email.policy submodule with a utf8 option that says whether to put unencoded UTF-8 into headers or to MIME encode it.
Yes. Still no new error handling required, still no new code path required of apps that use it. If an app doesn't add anything special, the users simply get generic error messages. "Unknown error while sending", "unable to send to <address>", that kind of thing.
Well, yeah but they don't get EAI support either if they don't set the utf8 option. IF you want EAI you have to change the client. I'm not saying any of these changes are a big deal, but they're more than zero. Regards, John Levine, john.levine@standcore.com Standcore LLC
On Monday 2 September 2019 16:38:46 CEST, John Levine wrote:
On Mon, 2 Sep 2019, Arnt Gulbrandsen wrote:
... Look at the python smtp client module. It does EAI and has a new SMTPNotSupportedError which is thrown if you send an EAI message and the server at the other end doesn't advertise SMTPUTF8. ...
I looked, and SMTPNotSupportedError isn't EAI-specific. Adding EAI support to a python app doesn't require it, because it was already required.
EAI raises that error in routines that never raised it before. I'd say that's an API change.
SMTPNotSupportedException is a subclass of SMTPException, which is raised for any SMTP-related. The method your have in mind has always raised SMTPException if the server refuses to relay to a given recipient. Old code that handles SMTPException gets SMTPNotSupportedException for free, it's just that it'll handle the proplem generically, not specifically, so it may report "remote server won't relay to ∀@example.org" when the actual problem is that the server has no SMTPUTF8 support.
I looked at it too, and if an application does nothing, it silently gets EAI support.
I looked at it, and if you don't say enable_SMTPUTF8=True it doesn't advertise SMTPUTF8 and you don't get EAI support. Look again.
https://aiosmtpd.readthedocs.io/en/latest/aiosmtpd/docs/controller.html#enab... The first sentence is the key. ("SMTP" is a legacy class, the recommended way is Controller nowadays.) I checked the actual code, and it matches the documentation. I love the wording BTW: "It’s very common to want to enable the SMTPUTF8 ESMTP option, therefore this is the default". Way to go.
Well, yeah but they don't get EAI support either if they don't set the utf8 option. IF you want EAI you have to change the client.
I'm not saying any of these changes are a big deal, but they're more than zero.
And I'm saying that if an application doesn't do any of them, then EAI has a nontrivial chance of working anyway. After a fashion. So the survey needs to take a position on software that contains no source-code-visible changes but may support EAI addresses anyway. How to find, how to classify. Whether to include. What to do about software that's intended to support EAI but contains no source-code-visible changes. Arnt
On Mon, 2 Sep 2019, Arnt Gulbrandsen wrote:
https://aiosmtpd.readthedocs.io/en/latest/aiosmtpd/docs/controller.html#enab...
The first sentence is the key. ("SMTP" is a legacy class, the recommended way is Controller nowadays.) I checked the actual code, and it matches the documentation.
Oh, OK, I was looking at the class in the standard library where it's not the default.
And I'm saying that if an application doesn't do any of them, then EAI has a nontrivial chance of working anyway. After a fashion.
Sometimes, yes. I suppose it's worth a checkbox for some EAI support through libraries. Regards, John Levine, john.levine@standcore.com Standcore LLC
participants (6)
-
Arnt Gulbrandsen -
Asmus Freytag -
Asmus Freytag (c)
-
John Levine -
Martin J. Dürst -
Tan Tanaka, Dennis