[Design] Email options: email submission to collections

[Brian Kirsch]

Hi Mimi,

 >>SMTP format addresses have certain restrictions on syntax.  Do any  SMTP
 >>restrictions (punctuation, no spaces, perhaps internationalization  
problems)
 >>now become restrictions on the names of collections?  Probably  not.  So
 >>there's at least some mapping step between the two.  I bet any  
proposed spec
 >>starts with "strip whitespace" :) Not sure what else is needed  offhand.

FYI, there are quite a large number of restrictions on the email address 
format so yes
some type of mapping would be required.

As defined in RFC 2821 <http://tools.ietf.org/html/2821>, the local-part 
of an e-mail address allows up to 64 characters maximum and the domain 
name <http://en.wikipedia.org/wiki/Domain_name> a maximum of 255 
characters. The local-part "MUST BE treated as case sensitive. [...] 
However, exploiting the case sensitivity of mailbox local-parts impedes 
interoperability and is discouraged."

According to RFC 2822 <http://tools.ietf.org/html/2822>, the local-part 
of the e-mail may use any of these ASCII characters:

    * Uppercase and lowercase letters
    * The digits 0 through 9
    * The characters, ! # $ % & ' * + - / = ? ^ _ ` { | } ~
    * The character "." provided that it is not the first or last
      character in the local-part.




Mimi Yin wrote:

> See in-line below:
>
> On Jul 19, 2006, at 6:47 AM, Jared Rhine wrote:
>
>>
>>>> + How do addresses map to calendars? (1-1, 1 to many, many to 1)
>>>
>>>
>>> What are reasons for having multiple addresses per share?
>>
>>
>> Probably different operations per share.  One alias for all-day event
>> submissions, one alias for regular events, one for free-form items,  
>> one for
>> SMS.  One for deletions, one for searches.  Ideas only, for  
>> clarification;
>> not proposals.  I realize these other operations are not relevant  to 
>> the
>> discussion of the "email submission" case.
>
>
> So something like:
> event at osafofficecalendar.com
> task at osafofficecalendar.com
> eventtask at osafofficecalendar.com
> maileventtask at osafofficecalendar.com
>
> Would we be able to accept all permutations? maileventtask?  
> taskeventmail?
>
>>
>>>> + How are new addresses created?
>>>
>>>
>>> Auto-generated when a collection is shared.
>>
>>
>> Ah, you've moved on to a specific implementation model, ok.
>>
>> What scheme do you propose for address creation?  I suspect we must  
>> include
>> both components of the user -> collection pair.  Probably  
>> concatenated with
>> punctuation: "jared.work@" and "jared.personal@" perhaps.  Your idea?
>
>
> That might work. There are cases where you're not sharing a personal  
> collection, but one for the group. e.g. osaf.calendar...But we can't  
> probably get over that in the short-term.
>
> I'm tempted to allow users to personalize these email addresses in  
> whatever they way they want. My preference for automation was  
> motivated by my assumption that it would be easier to implement (less  
> UI).
>
>>
>> SMTP format addresses have certain restrictions on syntax.  Do any  SMTP
>> restrictions (punctuation, no spaces, perhaps internationalization  
>> problems)
>> now become restrictions on the names of collections?  Probably  not.  So
>> there's at least some mapping step between the two.  I bet any  
>> proposed spec
>> starts with "strip whitespace" :) Not sure what else is needed  offhand.
>>
>> But I can't help think the user needs some control over this; if my  
>> Chandler
>> share name is "Work (client)" or something, perhaps the person  would 
>> like to
>> be able to select the string that maps to in email (I think  parentheses
>> might be out as an allowed character too, btw).  I suppose the same  
>> problem
>> exists for any URLs you want to hand out to ("private" name used  now 
>> becomes
>> visible by others).  I'd guess our answer is to set the hassle  aside 
>> and
>> make them name their collections the way they want the email to  appear?
>
>
> We could do this in the short-term and see what interesting use cases  
> we run into.
>
>>
>> Brian mentions the "leaked address" problem as another motivator  for 
>> wanting
>> to be able to set and change the email alias used.
>
>
> Yes. How quickly do you think this might happen? Can we implement it  
> in a following release? Or are leaks likely to happen right away? In  
> other words, how often will users need to change collection email  
> addresses?
>
>>
>> If the email address is shown in say a Chandler dialog, I wonder  how it
>> determines what to display.  Did it ask the server for the name  
>> assigned and
>> use that?  Did it present a dialog to the user, with
>> whitespace/known-bad-email-characters stripped out, and ask the  
>> server to
>> use that address for this collection?  Who's driving?
>
>
> Do you mean who's driving, client or server?
>
>>
>> Does the user get to select whether an email address is  
>> autocreated?  A user
>> might reasonably wish to decline submissions.  Indeed, they might  
>> wish to
>> turn it off and on as an administrative function later.
>
>
> Yes, all possibilities.
>
>>
>> Feasibility?  Not convenient given current architectures, but  
>> there's at
>> least a few different ways to implement "auto-creation" of the  
>> address.  We
>> could go again for tight Cosmo integration.  During collection  
>> creation and
>> deletion on the server, Cosmo could update a relational table of valid
>> submission email addresses and the collection URLs they map to.   The 
>> MTA and
>> email robot would then look up in this table for each email submission
>> processed.
>
>
> So is it easier to build UI to have users pick their own email  
> addresses?
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design


-- 
Brian Kirsch 
Internationalization Architect/ Mail Service Engineer
Open Source Applications Foundation
543 Howard Street 5th Floor
San Francisco, CA 94105
http://www.osafoundation.org