I'm forwarding this because I indavertently discarded it since I've gotten back into the habit of dealing with regular spam on the lists.
Mary. -----Original Message----- From: Ned Freed [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 8:55 PM To: Brian E Carpenter Cc: General Area Review Team; Ned Freed; [EMAIL PROTECTED]; Chris Newman Subject: Re: Gen-ART LC review of draft-freed-sieve-environment-04.txt > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > Please resolve these comments along with any other Last Call comments > you may receive. > Document: draft-freed-sieve-environment-04.txt > Reviewer: Brian Carpenter > Review Date: 2008-03-28 > IETF LC End Date: 2008-04-11 > IESG Telechat date: (if known) > Summary: Clarifications requested > Comments: > For "domain", "host" and "remote-host", since sieve strings are UTF-8, > are these items expressed in UTF-8 or in ACE encoding? ACE encoding, of course. Nor do I believe this is worth calling out in this context. Domains and hosts appear in Sieve in many places besides this; if this is indeed an issue (and I'm convinced it is not) the place to address it is in the Sieve base specification. More generally, AFAIK the relationship between IDN and email has never been completely nailed down - this is a part of more general problem EAI is looking at. I suppose you could argue that since these particular values are environmental rather than message-related they might come under some other set of rules, but they are still part of email as a service so I don't think that flies. Now, it would be interesting and useful to have a Sieve extension to decode ACE encodings for domains. Or perhaps the right way to do it is with a special sort of comparator. But we're going to need a bunch of stuff in Sieve to accomodate all aspects of EAI. Maybe we should wait to see how that shakes out. > "remote-host" > => Host name of remote SMTP client, if applicable and > available. > It would be cleaner if this was explicitly stated to be the FQDN. Seems reasonable. I'll change it. > "remote-ip" > => IP address of remote SMTP client, if applicable and > available. > I think the representation should be defined. I assume it will be > dotted-decimal for IPv4, but for IPv6 will it be the format defined > for URIs (RFC 3986) or that defined for SMTP (RFC 2821)? Yes, good point. This has already been brought up and discussed on the Sieve list. I can't say I'm completely delighted with the alternatives, but the latter seemed like the most reasonable choice so we went with it. Ned _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
