Re: [Gen-art] Gen-ART LC review of draft-freed-sieve-environment-04.txt

Hi Ned,

On 2008-03-28 14:55, Ned Freed wrote:

>> > 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.

As long as you're sure that implementers will not be left
in doubt...
> 
> 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.

Indeed, that makes sense.

> 
>> >     "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.

Ack

> 
>> >     "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.

In this email-related context, I agree.

   Brian
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art