Subject: Re: Progress update: negotiation

From: Hiroshi Tamura <[email-masked]>
Date: Tue, 06 Feb 2001 16:07:03 +0900 (JST)

At first glance of draft-ietf-fax-content-negotiaion-04.txt,
lots of points are clarified, I think.

> The draft is all there now, but there are some specific points I would like 
> to discuss.  One in particular that the authors jointly feel would benefit 
> from group discussion has arisen from the late addition of a negotiate-down 
> example:  if the sender has an alternative that assumed _lower_ 
> capabilities than the version actually sent, should those lower 
> capabilities be described explicitly by a Content-alternatives 
> header?  When the draft is available, I'll post more details of this 
> issue.  Other points regarding which WG revciew is explicitly requested are:

Negotiation-down example itself is good. Thanks for taking it.

In my feeling, it is better to describe lower or baseline capabilities
in Content-alternatives explicitly, but not mandatory.
All terminals or software must support baseline one at least.

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

I understand under some conditions the receiver do not want to
announce his capabilities. If you take care, you can write something
in Appendix A(implementation issues).

>    o  Check the correct final disposition for lost message data (3.4)

An suitable type do not exist in the current definitions,
but "deleted" is ok for me.

>    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  Describe interaction between Content-alternative and
>       message/partial.  Is the discussion in RFC 2298 section 2.5
>       sufficient? (4)

Huum. Difficult to comment. I do not know soon. I hope it is sufficient.
How about describing something in Appendix A?

>    o  Special considerations for defining composite document
>       characteristics (e.g. MRC) in Content-alternative headers? (4)

I do not know the issue well. Is it diffcult to express?

>    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.

>    o  Discuss the options that should be exposed using Content-
>       alternative;  e.g. is it necessary to declare 'baseline'
>       capabilities.

As I said in the above, it is better, but not mandatory.

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

Regards,
--
Hiroshi Tamura, Ricoh Company, LTD.
E-mail: [email-masked]

---

From: Graham Klyne <[email-masked]>
Date: Thu, 15 Feb 2001 13:42:59 +0000

Tamura-san,

I've responded to the negotiate-down matter in a separate message.  Here, 
I'll make any response to the other comments you have raised.

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.

>in Appendix A(implementation issues).

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.
<<<

This is also covered in section A.5.

>can use it clearly. But, I leave it to the editors.

In consideration of the editorial effort that will be needed to separate 
this, unless someone says this is likely to be used in another 
specification I propose to leave it where it is.

>How about describing something in Appendix A?

Unless someone comes up with specific concerns, I don't propose to add 
anything.

>I do not know the issue well. Is it diffcult to express?

It could be difficult.  I think it is a theoretical issue that takes us 
into a level of considerable extra complexity with zero-to-marginal utility.

>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?

>As I said in the above, it is better, but not mandatory.

See separate message.

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

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.)

The others I think are all in the prescribed form.  At some stage we'll 
probably need to extract the templates and send them to the right mailing 
address for IANA to action.

#g

---

From: Graham Klyne <[email-masked]>
Date: Thu, 15 Feb 2001 13:13:49 +0000

Tamura-san,

Again, thank you for your thoughts and comments.  Here, I'll try to pick up 
the main outstanding item...

>All terminals or software must support baseline one at least.

I've been thinking about this a little more.  In writing a protocol 
specification, I think the important matter to cover is that conforming 
implementations behave correctly over a reasonably wide range of 
circumstances.  Or: to minimize surprises.  I think that simply declaring a 
feature as desirable but not mandatory doesn't really further this goal.

Applying this approach to the matter of sender capability declarations and 
content negotiation, here are the possible scenarios (I think these cover 
all the possibilities):
(a) Receiver capabilities exactly match the data sent.
(b) Receiver has higher feature capabilities that match some alternative 
offered by the sender.
(c) Receiver has higher feature capabilities than the data sent, but these 
don't match any higher features are offered by the sender.
(d) Receiver has lower feature capabilities that match an alternative 
offered by the sender.
(e) Receiver has lower feature capabilities that do not match any 
alternative offered by the sender.

What are the reasonably desired outcomes?
(i) Receiver displays data and reports success.
(ii) Receiver does not display data and requests alternative, supplying its 
own capabilities so that the sender can select an alternative.
(iii) Receiver does not display data and reports failure.

These would be applied as:
(a) -> (i)
(b) -> (ii)
(c) -> (i)
(d) -> (ii)
(e) -> (ii) or (iii)?

I suggest:  if there is a reasonable chance that usable alternative data is 
available then simply reporting failure is not a helpful 
outcome.  Therefore the more useful outcome for case (e) would be action (ii).

The possible disadvantage in this case would be that if the sender does not 
have a suitable alternative, an additional round-trip message may be 
incurred (sections 3.3, 6.3).

So, if we accept that (ii) is the right way to respond in case (e), there 
is nothing to be gained in advertising features lower than those actually 
sent.  Otherwise if (iii) is the preferred response, then the lower 
capabilities MUST be sent.

Because there is a general presumption of a universally supported baseline 
format (Section 2.1.1, para 3) I tend to prefer option (ii).

I think the receiver's behaviour is the point of debate, then the issue of 
whether the sender declares lesser feature support follows from 
that.  Either way, I think some clarification in the document will be required.

#g

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

---

From: Hiroshi Tamura <[email-masked]>
Date: Fri, 16 Feb 2001 09:03:19 +0900 (JST)

> group's opportunity to voice any disagreements.

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

> may apply to the current transaction only.

Good.

> >can use it clearly. But, I leave it to the editors.

I see.

> I tend to agree.  This might be an issue to be covered in an offramp 

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 think it's helpful to highlight any new headers defined.)

Yes, we may need AD advice.

Regards,

---

From: Hiroshi Tamura <[email-masked]>
Date: Fri, 16 Feb 2001 11:19:03 +0900 (JST)

Short comments.

> incurred (sections 3.3, 6.3).

Oh, that's right.

> format (Section 2.1.1, para 3) I tend to prefer option (ii).

I also prefer (ii) in this case, although it may cause
additional message as the above.

> that.  Either way, I think some clarification in the document will be required.

I think so, too. Thank you for your thoughful comments.

Regards,