Subject: [Ietf-calsify] Section 4.1 Content Lines: x-name

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Mon Aug 21 20:38:27 2006

In section 4.1 Content Lines of RFC 2445 it says:

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

The comment for x-name is in contradiction with the text in section
4.8.8.1 Non-standard Properties as well as the text in section 7.2
Registration of New Properties.

New text proposed:

 > x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
 > ; Reserved for non-standard names. Can be used by bilateral
 > ; agreement.

Cheers,
Bernard

---

From: batsonjay at plumcanary.com (Jay Batson)
Date: Mon Aug 21 20:45:35 2006

> > ; Reserved for non-standard names. Can be used by bilateral

+1

-------------
Jay Batson
[email-masked]
+1-978-824-0111 (w)
+1-978-758-1599 (m)

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Tue Aug 22 06:46:56 2006

Hi Bernard,

>  > ; Reserved for non-standard names. Can be used by bilateral

What does 'bilateral agreement' mean? iCalendar has no concept of content 
negotiation between different clients/servers so I think that is 
meaningless. Certainly I am not aware of anyone who checks to see whether 
X- items are acceptable to a receiving entity.

I also don't like the use of 'non-standard' here. In fact what I would like 
to see is vendors actually registering their properties so that 
implementations may choose to inter operate if they so desire. To allow 
that to work we need to setup the IANA registry to support vendor defined 
properties, and we need a way to register vendorid's (note that ACAP has 
already setup a vendor id registry that is also being used by some IMAP 
extensions so we could re-use that, though the syntax would need to be 
checked).

So I propose the following text instead:

 > ; Reserved for private names which may or may not be registered.

-- 
Cyrus Daboo

---

From: TimHare at comcast.net (Tim Hare)
Date: Wed Aug 23 18:21:57 2006

Bilateral agreement between which two parties? 

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jay Batson
Sent: Monday, August 21, 2006 11:45 PM
To: Bernard Desruisseaux
Cc: Calsify WG
Subject: Re: [Ietf-calsify] Section 4.1 Content Lines: x-name

On Aug 21, 2006, at 11:37 PM, Bernard Desruisseaux wrote:

> > ; Reservered for experimental use. Not intended for use in ; 
> > released products.
>
> > ; Reserved for non-standard names. Can be used by bilateral ; 
> > agreement.

+1

-------------
Jay Batson
[email-masked]
+1-978-824-0111 (w)
+1-978-758-1599 (m)

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: TimHare at comcast.net (Tim Hare)
Date: Wed Aug 23 18:39:51 2006

Allowing vendor registration of extensions OR negotiation of bilateral
agreements about x-names _does_ move interoperability along, but I don't
think that it "simplifies" 2445/6/7.  In my personal opinion I would rather
see language that says that x-names are only guaranteed to be interoperable
between two identical instances of one vendor's software and that there is
no guarantee of interoperability when x-name collisions occur.  Registration
or x-name capability negotiation should be left to a later enhancement of
the standard, in my opion; trying to add such language now only seems to me
to slow down adoption of the "simplified" standard, and probably also incurs
delays in implementation of the standard.

I may be na?ve on this subject, not being a calendar developer, but
common-sense reasoning leads me to believe that it is easier to restrict any
given implementation to simplified behavior than it is to add new function
to improve interoperability, because the restriction is a subset of already
working code. 

Tim Hare

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Tuesday, August 22, 2006 9:47 AM
To: Bernard Desruisseaux; Calsify WG
Subject: Re: [Ietf-calsify] Section 4.1 Content Lines: x-name

Hi Bernard,

--On August 21, 2006 11:37:49 PM -0400 Bernard Desruisseaux
<[email-masked]> wrote:

>  > ; Reserved for non-standard names. Can be used by bilateral  > ; 
> agreement.

I also don't like the use of 'non-standard' here. In fact what I would like
to see is vendors actually registering their properties so that
implementations may choose to inter operate if they so desire. To allow that
to work we need to setup the IANA registry to support vendor defined
properties, and we need a way to register vendorid's (note that ACAP has
already setup a vendor id registry that is also being used by some IMAP
extensions so we could re-use that, though the syntax would need to be
checked).

--
Cyrus Daboo