Eric Allman wrote: > A couple of quick comments: > > It isn't clear from the draft if this is intended to be Standards Track; > I assume it is. My apologies. The intended state is Experimental. As I explained just now on the APPS-REVIEW list: *** I think this document should be Experimental. Implementation and deployment experience will tell us whether this approach has value. If it does, then we may want to abstract from that experience to design a more general approach along the lines that Barry has described [1]. I have received indications from several large entities providing both email and XMPP-based IM services that they will likely deploy this technology. The same may be true of one or more mail user agents. If and when that happens, I will report back (or ask them to do so) regarding their experience. *** [1] http://www1.ietf.org/mail-archive/web/apps-review/current/msg00063.html > I don't see any reason why a new proposed standard should allow obsolete > syntax (specifically, obs-FWS in section 2). Another reviewer pointed that out as well. As a result, in my working copy I have changed that to: "Jabber-ID:" [FWS] pathxmpp [FWS] CRLF > Given that the other official standards are named "XMPP" rather than > "Jabber", why isn't the field name "XMPP-ID"? Mindshare. Real people know what "Jabber" is. Only us geeks know what "XMPP" is. Think "email" vs. "SMTP", "web" vs. "HTTP", etc. > The forgery discussion in section 5 might reference 4871 (DKIM-BASE). That too has been pointed out by another reviewer. In my working copy I have the following text: *** Including the Jabber-ID header among the signer header fields in DomainKeys Identified Mail (DKIM) can help to mitigate against forging of the header (see [DKIMSIG]). *** (Where [DKIMSIG] is a reference to RFC 4871.) Thanks for the review. Peter -- Peter Saint-Andre https://stpeter.im/
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf