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

To be clear, I don't think there's any sort of confusion about the
specific subproblem of IDN-encoded domain names - Sieve currently treats
these in all cases as ASCII strings.

More generally, howwever, there's going to be a significant issue aligning
Sieve with the EAI work. Better domain IDN support is bound to come as  part of
that. But given that there are still unresolved issues in this space (e.g., the
recent debate about transcoding of addresses with UTF-8 in the domain to IDN
formats), I think any attempt to deal with this now would be premature.
Hopefully once the EAI experiment is in place an EAI-in-Sieve specification can
and will be written that covers all this plus a lot of other stuff.

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

I just wish the RFC 2821-defined format wasn't quite so ugly. But it is way too
late to change.

In any case, I've now posted a revised version that incorporates all of these
changes.

And thanks for the feedback.

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