RE: IESG comments on draft-ietf-vpim-hint

> I was not among the originators of this RFC, so please regard my comments as
> personal ones and not representing whole goup.

> > > 1) Allow x-message-context tags for proprietry implementations
> >
> > Given the incredibly poor history of x- tags in other
> > protocols I see no chance
> > the IESG will buy into this. Heck, I didn't have a problem
> > personally with
> > vendor-specific tags, but I have a big problem with x- tags.
> >
> > This also begs the question of why, since coding support for
> > a new sort of
> > message in a client is unquestionably a significant
> > undertaking, writing a
> > short description of it is seen as so onerous.

> It appears to me to be non-realistic. When we had discussions in the group
> regarding specific values some contraversial ones were taken out with
> argument that they are not generic enough and can always be handled using
> x-context approach.

There's a huge difference between the items that appear in the core
specification of an extensible facility, standardized items that appear
subsequently, and items specified by vendors later. In particular, the bar in
the first case is extremely high. The bar in the second and third cases is 
much lower.

In other words, saying that something is too controversial for the base
specification is not the same as saying it is unsuitable for specification
later. Indeed, base specifications of facilities have a way of introducing
clarity and ordering that facilitates subsequent development.

> I know that in systems we make we quite often introduce experimental
> contraversioal message-contexts (IM, mms, video, picture-messages, etc.),
> which sometimes evolve into generic ones and sometimes are not used outside
> of prototype or customer-specifc system.

Then there's no need to bother anyone with any of it.

> Blocking this from happening will induce using additonal header like
> x-message-context for these cases with its own values.

The experience with media types has been exactly the opposite. x- types created
problems rather than solving them.

Additionally, if the demand for this feature is sufficient to induce such
behavior, I fail to see why we're not drowning in a plethora of random header
fields of this sort.

> In my opinion this will not make message-context more generic, rather make
> handling more complicate and less robust.

Well, the present document doesn't allow for x- values either, so it would seem
the consensus of the group is against you on this.

Remember, while the IESG would like to see vendor contexts eliminated, it
doesn't insist on it. All the IESG insists on is that there be some
specification of the various message contexts available somewhere. This is more
or less equivalent to how media types are handled today.

				Ned
----------------------------------------------------------
This message was sent to you, since you are subscribed to
[email protected]. You can manage your subscription at
http://www.neystadt.org/cgi-bin/majordomo