[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Progress update: negotiation
> 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  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.
> > > 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.
> > > 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.
Hiroshi Tamura, Ricoh Company, LTD.