rfc

As many people may already be aware, correctly validating email addresses can be somewhat of a nightmare. You can search all day long for a C# regex that matches the current RFC standards, and you'll find different regex expressions that give different results. If you look at http://en.wikipedia.org/wiki/Email_address#Local_part , you'll see that a period at the beginning or end of the local part is not allowed. Two consecutive periods are also not allowed. However, the following NUnit test proves that System.Net.MailMessage allows you to instantiate a MailMessage object for some invalid email

I have some comments about the OAuth draft RFC (specifically about some errors it contains), but I'm not sure what the accepted way is to make them. There's an email address at the bottom, so do I simply send mail there with the comments, or is there some IETF tool I should know about for tracking comments/issues? The OAuth mailing list would be my first guess. I found this through the IETF home page. The best late-process way to report an error is indeed to use the email address at the bottom of the document, and contact the author directory. Early stage discussions take place on mailing

What RFC would I refer to in order to find out if a leading underscore in the local part of an email address is acceptable? Example: _johndoe@hotmail.com Of course, this question can also apply to any leading special character. I found this line in Wikipedia, but couldn't find any reference within the RFC itself. Did I miss something here? Local part The local-part of the email address may use any of these ASCII characters RFC 5322 Section 3.2.3: Quoting RFC5322. Section 3.4.1 says: An addr-spec is a specific Internet identifier that contains a locally interpreted string followed by the at

Our company has developed its own CMS based on Zend (version 1.8.4). Switching to a new version is out of the question for the moment. We are using Zend Mail for sending (multipart) messages with embedded images ( Content-Disposition: inline; ) and downloadable attachments ( Content-Disposition: attachment; ). A few days ago, a customer reported problems opening such a mail on his Apple iPhone 5 (internal mail client): In the inbox the mail was indeed marked with a symbol indicating that the mail has attachments. However, after opening the mail, the attachment was not visible. The problem does

项目进展已经过半了，贴上一份我的项目进度计划 红色的是没有能够完成的，或有疑问的。 进入FD、SD基本每天都有计划的，同时还有一份问题总结，将每天的问题列出来，没有完成的按照其重要程度进行了分类。 大家提提看法，可以交流交流。 准备阶段-PN 制定项目开发计划 (file ref: H:\P2004028\CMM文档\开发计划\D_P2004028_COSX_Schedule_20040510_cn.xls ) 制定SCM计划 [现在直接在SPIF中完成!!] 理解基本式样书 [1.项目背景 ●COS-X的IPv6对应状况 ◇基本协议的实装完了 ◇重要上层协议除掉SNMP外基本实装完成 ◇本项目作为重点开发项目，正在按顺序进行开发 ●SNMP的状况（一般动向） ◇是网络管理的唯一标准协议 ◇协议的版数有v1～v3这3个 →现在（IPv4）为v1。普及．安全方面有难度 →v2完成度较低，没有普及的趋势 →v3为安全对应的完成版 ●COS-X的SNMP功能状况 ◇ISODE7.0基础上与SNMPv1/SMIv1对应 ◇ISODE开发终止，维护方面有难度 →对SNMPv3的对应不可能 →障碍脆弱性的修正不可期待 ◇用户期待SNMPv3/SMIv2对应 2.开发目标及范围 ●IPv6对应装置开发基盘的整备 ◇对装置状态监视管理的对应 ◇本开发中主要协议的实装基本完成

In theory, the set of Request For Comments (RFC) contain everything that a developer needs to know to build an SMTP client. However, it is not always easy to know which RFCs need to be considered and which ones can be ignored. Does anyone have an RFC roadmap to steer developers through this? By RFC roadmap, I mean: A complete list of RFCs that need to be read and understood, in order to develop an SMTP client. An indication of which RFCs no longer need to be considered, because they have been superseded. A summary of the relevant RFCs. Detail on how the relevant RFCs interrelate to each other.

I have found conflicting information about dot stuffing when transmitting an email. stuff a dot if the line contains a single dot (to avoid premature termination) stuff a dot to every line stat starts with a dot stuff a dot to (1) and to every line part of a quoted-printable message part only Can anyone clarify? According to the SMTP standard RFC 5321, section 4.5.2: http://tools.ietf.org/html/rfc5321#section-4.5.2 To allow all user composed text to be transmitted transparently, the following procedures are used: Before sending a line of mail text, the SMTP client checks the first character of

I have an application that takes all the parameters in the url like this: /category/subcategory/sub-subcategory . I want to be able to give out extra parameters at the end of the URL, like page-2/order-desc . This would make the whole URL into cat/subcat/sub-subcat{delimiting-character}page-2/order-desc . My question is: what characters could I use as {delimiting-character} . I tend to prefer ":" as I know for sure it will never appear anyplace else but I don't know if it would be standard compliant or at least if it will not give me problems in the future. As I recall vimeo used something

I have a custom json request class to upload multi-part files to server this class in an Android application , it works fine when I add English words as keys and values(these keys and values are one part) but when I use any Arabic word, it writes unknown words like "'D*F*9". Before I write these values to ByteArrayOutputStream object, every thing works fine, and I can see Arabic words. This is the get Body Content Type method for the all class @Override public String getBodyContentType() { return "multipart/form-data;charset=UTF-8;boundary=" + boundary; //return "application/json; charset=UTF