Subject: 2445:4.1 (x-name) is misleading.

From: "David L. Nicol" <[email-masked]>
Date: Wed, 15 Aug 2001 14:43:28 -0500

2445:4.1 (x-name) is misleading.  At least it mislead me.  But I
am noti=oriously clueless.

"Shannon J. Clark" wrote:
> 
> [...] look at RFC2445 starting at page 133 for a general discussion of X-
> properties.
> 
> Shannon

thanks.  Section 4.8.8.1 is comforting.

The passage in 4.1 

     x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
     ; Reservered for experimental use. Not intended for use in
     ; released products.

misled me.  I think I have a wider conception of what a "released product"
is and a narrower conception of what "experimental use" means than the
authors of the document.
I understood the passage to mean that x-names were only
to be used within clean-room kinds of situations to test features which
might get added into later versions of 2445.

A clearer rephrasing might more closely resemble the definition of
SMTP EXTENSION-FIELD in rfc822:

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

Maybe the lines in 4.1 describing x-name might be rewritten,
less ominously, like so:

     x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
     ; The "X-" parameter name space is reserved for user extensions.

-- 
                                           David Nicol 816.235.1187
"Tomato!"

---

From: John Stracke <[email-masked]>
Date: Thu, 16 Aug 2001 08:30:41 -0400

David L. Nicol wrote:

>2445:4.1 (x-name) is misleading.  At least it mislead me.
>
Actually, I think you're right in your reading of it; it's just that, 
since 2445 was written, everybody's understanding of X- has drifted.   
 I, for one, had forgotten that it was forbidden in released software, 
and had come to think of it as meaning the same thing it does in 
RFC-[2]822 headers: "use at your own risk".

However, on reflection, I suspect the approach taken in 2445 may be 
better for our purposes.  iCalendar properties interact so much that 
adding new ones may be somewhat risky.  By contrast, mail headers 
generally stand alone; about the only interaction I can think of is that 
Reply-To: overrides From:.

-- 
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |Reality is what refuses to go away when I stop|
[email-masked]|believing in it.                              |
\===============================================================/