RE: [VPIM] Analogy to Content-Duration for Faxes

John,

Writing a draft sounds good to me.  Submitting a draft is usually a good 
step to getting an idea considered seriously.

An example whose procedural model you might wish to follow is the 
charset/language feature registration proposal written by Paul 
Hoffman.  This was circulated and reviewed within and outside the conneg 
group, and has since been IETF-last-called as a private submission.

There's a mailing list for review of new feature registrations (noted in 
RFC 2506).  It would probably be sensible to at least notify the conneg 
list of any proposal you make, since some interested parties are here.  But 
(beyond some initial registrations) it is not the purpose of the conneg WG 
to approve all new feature registrations.

In your case (assuming VPIM has WG status), you may wish to present and 
progress it as a VPIM work item (with the chair's concurrence, of 
course).   There might be a case for making it a fax WG item.

BTW, as I understand it, an IETF-tree feature registration doesn't 
necessarily need to be standards track (though I think at least 
informational RFC publication is required).  But, if you want to reference 
the feature normatively from another standards track specification, then I 
think it would need to be standards track.

#g
--

At 01:31 PM 3/8/00 +0200, Neystadt, John wrote:
>So, what should be a way to advance with this, should I try to write a draft
>for this feature?
>
>John Neystadt
>[email protected]
>http://www.neystadt.org/john/
>
>
>
> > -----Original Message-----
> > From: Graham Klyne [mailto:[email protected]]
> > Sent: Wed, March 08, 2000 12:45 PM
> > To: Neystadt, John
> > Cc: conneg WG; IETF VPIM List; [email protected]
> > Subject: RE: [VPIM] Analogy to Content-Duration for Faxes
> >
> >
> > John,
> >
> > I think there's nothing wrong with a small RFC :-)
> >
> > <draft-ietf-conneg-content-features-02.txt> has already gone
> > forward for
> > last call, and the IESG review is (at least) partially done.
> > Also, there's
> > not an obvious linkage between registration of "pages" and the
> > "content-features:" header proposal, so I think they are
> > better kept separate.
> >
> > BTW, I think Larry's proposal was always to register "pages", as you
> > suggest, and that the reference to "UA-media" was simply a
> > (subsidiary)
> > possibility to qualify the kind of "page" being indicated.
> >
> > Regards,
> >
> > #g
> > --
> >
> >
> > At 11:38 PM 3/7/00 +0200, Neystadt, John wrote:
> > >ua-media doesn't fits well, we are not talking about user
> > agents here.
> > >
> > >I think registering media feaure "pages" is a better one.
> > >
> > >What should be done to go forward with this. It seems to
> > small item for an
> > >RFC, can't we take tremp and add it into
> > >draft-ietf-conneg-content-features.txt?
> > >
> > >John Neystadt
> > >[email protected]
> > >http://www.neystadt.org/john/
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Larry Masinter [mailto:[email protected]]
> > > > Sent: Thu, February 10, 2000 4:35 AM
> > > > To: [email protected]
> > > > Cc: Neystadt, John; IETF VPIM List; [email protected]
> > > > Subject: RE: [VPIM] Analogy to Content-Duration for Faxes
> > > >
> > > >
> > > >
> > > > # > Content-Features: pages=10
> > > >
> > > > # > to note a 10-page document.
> > > >
> > > > # Might even want to have an additional attribute to say what
> > > > sort of "page"
> > > > # you're talking about.
> > > >
> > > > RFC 2534 already registers 'ua-media' tag with values such as
> > > > 'screen-paged'
> > > > and 'stationery' (most likely the kind of pages you'd want
> > > > with faxes), and
> > > > a 'paper-size' tag with additional token values. At the time
> > > > RFC 2534 was
> > > > written, we were focusing mainly on media features for
> > > > recipients rather
> > > > than
> > > > for content; you might still want to characterize a fax
> > > > recipient as having
> > > > a maximum number of pages its willing to receive, though.
> > > >
> > > >
> > > >
> > > >
> >
> > ------------
> > Graham Klyne
> > ([email protected])
> >
> >

------------
Graham Klyne
([email protected])