Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 May 2000 18:39:12 +0930
From:      Greg Lehey <grog@lemis.com>
To:        Chris Fedde <chris@fedde.littleton.co.us>
Cc:        "Bill A. K." <billieakay@yahoo.com>, questions@FreeBSD.ORG
Subject:   Re: IE for FreeBSD Petition
Message-ID:  <20000522183912.B78939@freebie.lemis.com>
In-Reply-To: <200005220441.e4M4fBp08044@fedde.littleton.co.us>
References:  <20000522093603.B77130@freebie.lemis.com> <200005220441.e4M4fBp08044@fedde.littleton.co.us>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, 21 May 2000 at 22:41:11 -0600, Chris Fedde wrote:
> On Mon, 22 May 2000 09:36:03 +0930  Greg Lehey wrote:
>  +------------------
>> I think this is a very bad idea.  Look at your mail message for one
>> good reason why: Microsoft software is just plain broken.  You
>> probably don't even realise that your message was written without line
>> breaks.  Isn't it much easier to read like this?
>  +------------------
>
> Before we start calling the kettle black we might want to check the color
> of our own pot.  Your mailer included the following headers.
>
>     Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia
>     Phone: +61-8-8388-8286
>     Fax: +61-8-8388-8725
>     Mobile: +61-418-838-708
>     WWW-Home-Page: http://www.lemis.com/~grog
>
> Unless something has changed recently I don't beleave that these are
> valid headers by any interpretation of the appropriate RFCs.

Unless something has changed recently, I believe that these are valid
headers by interpretation of RFC 822:

 optional-field =
                 /  "Message-ID"        ":"   msg-id
                 /  "Resent-Message-ID" ":"   msg-id
                 /  "In-Reply-To"       ":"  *(phrase / msg-id)
                 /  "References"        ":"  *(phrase / msg-id)
                 /  "Keywords"          ":"  #phrase
                 /  "Subject"           ":"  *text
                 /  "Comments"          ":"  *text
                 /  "Encrypted"         ":" 1#2word
                 /  extension-field              ; To be defined
                 /  user-defined-field           ; May be pre-empted
 
 <snip>

     extension-field =
                   <Any field which is defined in a document
                    published as a formal extension to this
                    specification; none will have names beginning
                    with the string "X-">
 
     user-defined-field =
                   <Any field which has not been defined
                    in this specification or published as an
                    extension to this specification; names for
                    such fields must be unique and may be
                    pre-empted by published extensions>


 <snip>

     4.7.4.  EXTENSION-FIELD
 
             A limited number of common fields have  been  defined  in
        this  document.   As  network mail requirements dictate, addi-
        tional fields may be standardized.   To  provide  user-defined
        fields  with  a  measure  of  safety,  in name selection, such
        extension-fields will never have names  that  begin  with  the
        string "X-".
 
             Names of Extension-fields are registered with the Network
        Information Center, SRI International, Menlo Park, California.
 
     4.7.5.  USER-DEFINED-FIELD
 
             Individual users of network mail are free to  define  and
        use  additional  header  fields.   Such fields must have names
        which are not already used in the current specification or  in
        any definitions of extension-fields, and the overall syntax of
        these user-defined-fields must conform to this specification's
        rules   for   delimiting  and  folding  fields.   Due  to  the
        extension-field  publishing  process,  the  name  of  a  user-
        defined-field may be pre-empted
 
        Note:  The prefatory string "X-" will never  be  used  in  the
               names  of Extension-fields.  This provides user-defined
               fields with a protected set of names.
 
> At best these should be inside a Comments: header or perhaps
> preceded by an X- to indicate that they are not standard.  

As RFC 822 says, it's probably not a bad idea, but it's not required.
The worst problem I could encounter would be that some new extension
might redefine the meaning of one of my headers.  I suspect that's not
going to happen in the immediate future.

> Current convention appears to be to slap these into a xcard or vcard
> format encapsulated in MIME.

Do you have an RFC for this convention?  The format suggests
Microsoft.

Greg
--
When replying to this message, please copy the original recipients.
For more information, see http://www.lemis.com/questions.html
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000522183912.B78939>