Re: Progress update: negotiation

[Hiroshi Tamura <tamura@xxxxxxxxxxxxxxxx>]

> First, a general point:  the document contains a list of points for 
> consideration in a "review checklist" in appendix C.  This is to draw 
> attention to some points that we felt deserved wider consideration.  But if 
> we don't receive any views on any of these issues, the general plan is to 
> not change the specification.  We've made our decisions:  now is the 
> group's opportunity to voice any disagreements.

OK. I see.
I think so, too, as a chair.

> > >    o  Cache-control for recipient features? (e.g. colour offered for
> > >       selected senders only). (3.2.3)

> I've added a paragraph to section 6.2, which I think probably covers this 
> issue adequately.
> 
>  >>>
> An MDN response containing an 'alternative-preferred' disposition modifier 
> SHOULD also contain a 'Media-accept-features:' field [2] indicating the 
> capabilities that the sender should use in selecting an alternative form of 
> message data.  If this field is not supplied, the sender should assume some 
> baseline feature capabilities.  Receiver capabilities supplied with an 
> alternative-preferred disposition notification MUST NOT be cached:  they 
> may apply to the current transaction only.
> <<<

Good.

> > >    o  Define Content-alternative in a separate document? (Possibly,
> > >       because it might be used separately from the content negotiation
> > >       framework;  e.g. in a fashion similar to the HTTP vary: header.)
> > >       (4)
> >
> >If possible, another document is better so that other applications
> >can use it clearly. But, I leave it to the editors.

I see.

> > >    o  Add E164 address type for reporting fax offramp disposal?  (6.2)
> >
> >It seems to be difficult to take. Because, it has something to do with
> >G3 or G4 fax protocol itself. It is better NOT to address, I think.
> 
> I tend to agree.  This might be an issue to be covered in an offramp 
> gateway specification?

If possible, it is better to address this issue in it.
But, even in it, it may be very difficult.

> >Section 9(IANA...) is sufficient for registering headers or anything?

My question is,
for example, some more detailed descriptions are necessary,
such as RFC2302 or draft-ietf-fax-tiff-regbis-02.txt,,?

> I'll take AD advice on that.  In the absence of an IANA registry, I think 
> that definition in an RFC is all that is needed.  For now, that material is 
> a place-holder.  (Also, I am aware of separate ideas in formation for which 
> I think it's helpful to highlight any new headers defined.)

Yes, we may need AD advice.

Regards,
--
Hiroshi Tamura, Ricoh Company, LTD.
E-mail: tamura@xxxxxxxxxxxxxxxx