Subject: Re: [EAI] @ in Intranets

From: Shawn Steele <[email-masked]>
Date: Wed, 28 Oct 2009 19:36:53 +0000

> Yes, it would probably work. Of course, such local addresses are a problem, because some work
> will have to be done to change them when e.g. a page goes public.

> It's somehow similar to file: URIs, which are also local.

More similar, perhaps, to an Intranet web site where the full domain name isn't specified, nor available to the rest of the world.  In my experience such links are usually for the contact of an intranet web site or group or something and they never "go public."  (If they might go public, the full form would be much better.)

> Anyway, currently, the syntax of the mailto: URI/IRI requires an @, but in practice, 
> mailto: URIs/IRIs without an @ may get through, of course.

It seems common, in enterprises at least, to have such internal/intranet resources that aren't fully specified.  I wonder if perhaps the standard should allow that mailto: without an @ MAY be used for Intranet use only?  Of course I could argue that if it's for Intranet use only, then it doesn't need to be in an IETF standard :)  Since many tools work in both Internet and Intranet environments, it might be good to allow the common practice.

-Shawn

---

From: SM <[email-masked]>
Date: Wed, 28 Oct 2009 13:40:30 -0700

Hi Shawn,
At 12:36 28-10-2009, Shawn Steele wrote:
>It seems common, in enterprises at least, to have such 
>internal/intranet resources that aren't fully specified.  I wonder 
>if perhaps the standard should allow that mailto: without an @ MAY 
>be used for Intranet use only?  Of course I could argue that if it's 
>for Intranet use only, then it doesn't need to be in an IETF 
>standard :)  Since many tools work in both Internet and Intranet 
>environments, it might be good to allow the common practice.

By diverging from RFC 5321, you may be introducing some 
ambiguity.  Today's Intranet environment might be moved to the 
Internet tomorrow.  Your mailto:local-part will be qualified and you 
cannot tell where the message may end up.  Standardizing (not IETF) 
is generally less work.  If you do not take out the "@", you still 
have some semblance of an email address.  If you keep "At-domain", 
you make it easier for the IETF. :-)

I adopted an approach similar to yours many years ago in an 
environment that was not an Intranet.  I would not adopt the same 
approach now as the boundary between private and public is blurry.

Regards,
-sm