Draft Agenda for VPIM

Re: Draft Agenda for VPIM

Glenn,

> TUESDAY, July 16, 2002
> 0900-1130 Morning Sessions
> APP     fax&vpim  Internet Fax WG & Voice Profile for Internet Mail WG  
> 
> Anyway, on the meeting agenda, I would propose FAX goes first and that VPIM
> progresses in a similar order of events as we have done previously: 

Your proposal for FAX WG going first is ok for me. I live in Yokohama!
But, some FAX WG members do not stay at hotels and go there
directly from their home.

Dear Japanese FAX WG members:
If you take the first train in the morning and cannot go there,
please let us know very soon.

Regarding FAX WG agenda, I will let you know the next Tuesday, maybe.
The issues are mainly confirmation of status of I-Ds that FAX WG finished,
TIFF-FX, ESMTP CONNEG, Claudio's I-D, FAX in ENUM and ITU.
Please wait. 

Regards,
--
Hiroshi Tamura, Co-chair of IETF-FAX WG
E-mail: tamura <at> toda.ricoh.co.jp

AD review comments on draft-ietf-fax-esmtp-conneg-01.txt

Let's start with an obvious document issue, easily fixed: The IANA
considerations section. It currently says "This memo is not intended to create
any new issues for IANA." However, the document's primary goal is to define an
ESMTP extension, and registration of ESMTP extensions is an IANA activity. As
such, I suggest this section be changed to read "On publicatioj of this
document by the RFC Editor the IANA shall register the Content_Negotiation
ESMTP extension defined in section 2."

Another minor document issue is that the RFC Editor has a new policy that
references must be separated into normative and informative groups. In this
case I think there is effectively no separation: All three of the references
here appear normative to me. So the thing to do is change the title of section
9 to "NORMATIVE REFERENCES".

Another document issue is that this document begins with a SUMMARY but has no
ABSTRACT or INTRODUCTION. The RFC Editor wants to see a separate ABSTRACT and
INTRODUCTION section in all new RFCs. I would suggest keeping the current
SUMMARY as the ABSTRACT and writing a new INTRODUCTION, reiterating the
ABSTRACT but adding some additional background information if possible.

On to security considerations. What's there seems entirely appropriate.
However, there's are two other security considerations I believe deserve
mention: The possibility that a vulnerability will be disclosed by the
mechanism and the possibility of tampering with the result the mechanism
returns.

The first specific case that concerns me is that of a capability that is
typically handled by, say, a plugin that has been found to contain a security
vulnerability. Disclosure of support for this capability becomes tantamount to
disclosing a vulnerability.

The second case is one where a man in the middle changes the capabilities
associated with a given recipient. Here's a somewhat fanciful example: Suppose
the sender knows the recipient has the ability to view color documents so they
mark some things in red in what is otherwise a black and white document. But
someone interferes with the returned capabilities, making them say the
recipient only supports black and white. The document is duly downgraded, with
the result that the recipient doesn't see what the sender marked. (Of course
the man in the middle could have tampered with the document itself, but
modifying a document on the fly is a much more difficult proposition.)

I'm not suggesting that this facility be changed to address these issues,
merely that they be mentioned in the security considerations section.

Next up is failure modes. The model defined here seems simple enough: Client
asks server for capabilities for a given recipient and the server either
returns those capabilities or fails with a CONNEG-specific error code.

I wonder, however, if this isn't too simple. A server may have no trouble
delivering mail to a given recipient but might be unable to return that
recipient's capabilities. And this could be either a temporary or permanent
failure: The directory containing this information could be offline, or it
could be the case that this information simply isn't available for this
particular recipient.

Of course a client that receives a 504 can always retry the recipient without
the CONNEG parameter if it is willing to operate in the absence of capability
information. But it may want to take different actions depending on whether the 
failure is temporary or permanent: I could easily see sending some sort of
default for a permanent failure while waiting to retry in the even of a
temporary failure.

I therefore suggest that an additional 404 status code be defined that can be
returned when the server experiences a temporary failure getting capability
information.

The unconditional use of a failure code when capabilities aren't available also
concerns me. While it is true the client can simply reissue the RCPT TO without
the CONNEG parameter, handling this case effectively stalls the SMTP dialogue.
(That is, the client has to wait for the response to the RCPT TO before it
knows how to proceed.) And dialogue stalls are a significant operational issue
in practice. I therefore suggest that the mechanism be changed to allow a
CONNEG parameter value. The value would be, say, either REQUIRED or OPTIONAL.
The REQUIRED value would result in the same behavior currently described in the
document. The OPTIONAL case, however, would instruct the server to proceed
normally and return a _success_ status when the capabilities aren't available.
A corresponding 2xx code would need to be defined for this case.

This document also fails to specify what enhanced status code should be
returned in the event the server is unable to return capabilities information.
Looking at the list in RFC 1893 I'd say one possibility is x.3.3, system not
capable of selected feature. I also note in passing that there are no examples
of CONNEG failures in the examples section. Some examples of this sort need to
be added.

Another interesting case that could arise in practice is where a server is
configured to require authentication, integrity, or privacy services before
capability information can be returned. I think the document needs to discuss
this case, saying that if such requirements have not been met the CONNEG
extension should not be offered in the EHLO response. (Note that successful
security negotiation already involves repeating EHLO.)

Although several examples of returned capabilities are shown, the document
isn't very specific about how capabilities have to be formatted. In particular,
I'd expect to see capabilities often stored as a single string without any line
breaks. Some advice on how to take such a string and format it for inclusion in
the reponse seems warranted.

According to this document the only capabilities that can be returned are those
defined in RFC 2879, which is FAX-specific. I realize this document is a
product of the FAX WG, but is this really appropriate? Should more general
capabilites return be allowed? And if not, shouldn't this extension be called
FAXCONNEG or something similar?

Finally, this document makes passing reference to "use in relay scenarios". I
think some elaboration of this might be in order. In particular, I see at least
two scenarios that involve relaying: One where a server knows it will
subsequently relay the message but offers up capability information by proxy,
and another where the client is an intermediary service with message
downgrading capabilities.

That's it!

				Ned

Re: AD review comments on draft-ietf-fax-esmtp-conneg-01.txt

Freed-san,

Thank you for checking document and clarify issues.
I will study issues and respond next week.

ned.freed <at> mrochek.com wrote:
>
>Let's start with an obvious document issue, easily fixed: The IANA
>considerations section. It currently says "This memo is not intended to create
>any new issues for IANA." However, the document's primary goal is to define an
>ESMTP extension, and registration of ESMTP extensions is an IANA activity. As
>such, I suggest this section be changed to read "On publicatioj of this
>document by the RFC Editor the IANA shall register the Content_Negotiation
>ESMTP extension defined in section 2."
>
>Another minor document issue is that the RFC Editor has a new policy that
>references must be separated into normative and informative groups. In this
>case I think there is effectively no separation: All three of the references
>here appear normative to me. So the thing to do is change the title of section
>9 to "NORMATIVE REFERENCES".
>
>Another document issue is that this document begins with a SUMMARY but has no
>ABSTRACT or INTRODUCTION. The RFC Editor wants to see a separate ABSTRACT and
>INTRODUCTION section in all new RFCs. I would suggest keeping the current
>SUMMARY as the ABSTRACT and writing a new INTRODUCTION, reiterating the
>ABSTRACT but adding some additional background information if possible.
>
>On to security considerations. What's there seems entirely appropriate.
>However, there's are two other security considerations I believe deserve
>mention: The possibility that a vulnerability will be disclosed by the
>mechanism and the possibility of tampering with the result the mechanism
>returns.
>
>The first specific case that concerns me is that of a capability that is
>typically handled by, say, a plugin that has been found to contain a security
>vulnerability. Disclosure of support for this capability becomes tantamount to
>disclosing a vulnerability.
>
>The second case is one where a man in the middle changes the capabilities
>associated with a given recipient. Here's a somewhat fanciful example: Suppose
>the sender knows the recipient has the ability to view color documents so they
>mark some things in red in what is otherwise a black and white document. But
>someone interferes with the returned capabilities, making them say the
>recipient only supports black and white. The document is duly downgraded, with
>the result that the recipient doesn't see what the sender marked. (Of course
>the man in the middle could have tampered with the document itself, but
>modifying a document on the fly is a much more difficult proposition.)
>
>I'm not suggesting that this facility be changed to address these issues,
>merely that they be mentioned in the security considerations section.
>
>Next up is failure modes. The model defined here seems simple enough: Client
>asks server for capabilities for a given recipient and the server either
>returns those capabilities or fails with a CONNEG-specific error code.
>
>I wonder, however, if this isn't too simple. A server may have no trouble
>delivering mail to a given recipient but might be unable to return that
>recipient's capabilities. And this could be either a temporary or permanent
>failure: The directory containing this information could be offline, or it
>could be the case that this information simply isn't available for this
>particular recipient.
>
>Of course a client that receives a 504 can always retry the recipient without
>the CONNEG parameter if it is willing to operate in the absence of capability
>information. But it may want to take different actions depending on whether the 
>failure is temporary or permanent: I could easily see sending some sort of
>default for a permanent failure while waiting to retry in the even of a
>temporary failure.
>
>I therefore suggest that an additional 404 status code be defined that can be
>returned when the server experiences a temporary failure getting capability
>information.
>
>The unconditional use of a failure code when capabilities aren't available also
>concerns me. While it is true the client can simply reissue the RCPT TO without
>the CONNEG parameter, handling this case effectively stalls the SMTP dialogue.
>(That is, the client has to wait for the response to the RCPT TO before it
>knows how to proceed.) And dialogue stalls are a significant operational issue
>in practice. I therefore suggest that the mechanism be changed to allow a
>CONNEG parameter value. The value would be, say, either REQUIRED or OPTIONAL.
>The REQUIRED value would result in the same behavior currently described in the
>document. The OPTIONAL case, however, would instruct the server to proceed
>normally and return a _success_ status when the capabilities aren't available.
>A corresponding 2xx code would need to be defined for this case.
>
>This document also fails to specify what enhanced status code should be
>returned in the event the server is unable to return capabilities information.
>Looking at the list in RFC 1893 I'd say one possibility is x.3.3, system not
>capable of selected feature. I also note in passing that there are no examples
>of CONNEG failures in the examples section. Some examples of this sort need to
>be added.
>
>Another interesting case that could arise in practice is where a server is
>configured to require authentication, integrity, or privacy services before
>capability information can be returned. I think the document needs to discuss
>this case, saying that if such requirements have not been met the CONNEG
>extension should not be offered in the EHLO response. (Note that successful
>security negotiation already involves repeating EHLO.)
>
>Although several examples of returned capabilities are shown, the document
>isn't very specific about how capabilities have to be formatted. In particular,
>I'd expect to see capabilities often stored as a single string without any line
>breaks. Some advice on how to take such a string and format it for inclusion in
>the reponse seems warranted.
>
>According to this document the only capabilities that can be returned are those
>defined in RFC 2879, which is FAX-specific. I realize this document is a
>product of the FAX WG, but is this really appropriate? Should more general
>capabilites return be allowed? And if not, shouldn't this extension be called
>FAXCONNEG or something similar?
>
>Finally, this document makes passing reference to "use in relay scenarios". I
>think some elaboration of this might be in order. In particular, I see at least
>two scenarios that involve relaying: One where a server knows it will
>subsequently relay the message but offers up capability information by proxy,
>and another where the client is an intermediary service with message
>downgrading capabilities.
>
>That's it!
>
>				Ned
>

Kiyoshi Toyoda

RE: AD review comments on draft-ietf-fax-esmtp-conneg-01.txt

Ned,
Thank you for your attention and feedback on
draft-ietf-fax-esmtp-conneg-01.txt and previously
draft-ietf-fax-tiff-fx-regbis-04.txt. There, however, appears to be some
oversight as draft-ietf-fax-tiff-fx-reg-01.txt was last called at the same
time or before these drafts yet it has not received any feedback. This is
concerning because tiff-fx-reg and tiff-fx were identified by you and John
Klensin as deserving of priority to try and realize a mid-September 02
approval by IESG as Draft Standards. Given that we are approaching mid-June
it is now questionable whether end-of-2002 is possible for approval by IESG
as Draft Standards.

Please comment.

Lloyd

> -----Original Message-----
> From: ned.freed <at> mrochek.com [mailto:ned.freed <at> mrochek.com]
> Sent: Sunday, June 09, 2002 1:45 PM
> To: ietf-fax <at> imc.org; dcrocker <at> brandenburg.com;
> ktoyoda <at> rdmg.mgcs.mei.co.jp
> Cc: ned.freed <at> mrochek.com; paf <at> cisco.com
> Subject: AD review comments on draft-ietf-fax-esmtp-conneg-01.txt
> 
> 
> 
> Let's start with an obvious document issue, easily fixed: The IANA
> considerations section. It currently says "This memo is not 
> intended to create
> any new issues for IANA." However, the document's primary 
> goal is to define an
> ESMTP extension, and registration of ESMTP extensions is an 
> IANA activity. As
> such, I suggest this section be changed to read "On 
> publicatioj of this
> document by the RFC Editor the IANA shall register the 
> Content_Negotiation
> ESMTP extension defined in section 2."
> 
> Another minor document issue is that the RFC Editor has a new 
> policy that
> references must be separated into normative and informative 
> groups. In this
> case I think there is effectively no separation: All three of 
> the references
> here appear normative to me. So the thing to do is change the 
> title of section
> 9 to "NORMATIVE REFERENCES".
> 
> Another document issue is that this document begins with a 
> SUMMARY but has no
> ABSTRACT or INTRODUCTION. The RFC Editor wants to see a 
> separate ABSTRACT and
> INTRODUCTION section in all new RFCs. I would suggest keeping 
> the current
> SUMMARY as the ABSTRACT and writing a new INTRODUCTION, 
> reiterating the
> ABSTRACT but adding some additional background information if 
> possible.
> 
> On to security considerations. What's there seems entirely 
> appropriate.
> However, there's are two other security considerations I 
> believe deserve
> mention: The possibility that a vulnerability will be disclosed by the
> mechanism and the possibility of tampering with the result 
> the mechanism
> returns.
> 
> The first specific case that concerns me is that of a 
> capability that is
> typically handled by, say, a plugin that has been found to 
> contain a security
> vulnerability. Disclosure of support for this capability 
> becomes tantamount to
> disclosing a vulnerability.
> 
> The second case is one where a man in the middle changes the 
> capabilities
> associated with a given recipient. Here's a somewhat fanciful 
> example: Suppose
> the sender knows the recipient has the ability to view color 
> documents so they
> mark some things in red in what is otherwise a black and 
> white document. But
> someone interferes with the returned capabilities, making them say the
> recipient only supports black and white. The document is duly 
> downgraded, with
> the result that the recipient doesn't see what the sender 
> marked. (Of course
> the man in the middle could have tampered with the document 
> itself, but
> modifying a document on the fly is a much more difficult proposition.)
> 
> I'm not suggesting that this facility be changed to address 
> these issues,
> merely that they be mentioned in the security considerations section.
> 
> Next up is failure modes. The model defined here seems simple 
> enough: Client
> asks server for capabilities for a given recipient and the 
> server either
> returns those capabilities or fails with a CONNEG-specific error code.
> 
> I wonder, however, if this isn't too simple. A server may 
> have no trouble
> delivering mail to a given recipient but might be unable to 
> return that
> recipient's capabilities. And this could be either a 
> temporary or permanent
> failure: The directory containing this information could be 
> offline, or it
> could be the case that this information simply isn't 
> available for this
> particular recipient.
> 
> Of course a client that receives a 504 can always retry the 
> recipient without
> the CONNEG parameter if it is willing to operate in the 
> absence of capability
> information. But it may want to take different actions 
> depending on whether the 
> failure is temporary or permanent: I could easily see sending 
> some sort of
> default for a permanent failure while waiting to retry in the 
> even of a
> temporary failure.
> 
> I therefore suggest that an additional 404 status code be 
> defined that can be
> returned when the server experiences a temporary failure 
> getting capability
> information.
> 
> The unconditional use of a failure code when capabilities 
> aren't available also
> concerns me. While it is true the client can simply reissue 
> the RCPT TO without
> the CONNEG parameter, handling this case effectively stalls 
> the SMTP dialogue.
> (That is, the client has to wait for the response to the RCPT 
> TO before it
> knows how to proceed.) And dialogue stalls are a significant 
> operational issue
> in practice. I therefore suggest that the mechanism be 
> changed to allow a
> CONNEG parameter value. The value would be, say, either 
> REQUIRED or OPTIONAL.
> The REQUIRED value would result in the same behavior 
> currently described in the
> document. The OPTIONAL case, however, would instruct the 
> server to proceed
> normally and return a _success_ status when the capabilities 
> aren't available.
> A corresponding 2xx code would need to be defined for this case.
> 
> This document also fails to specify what enhanced status code 
> should be
> returned in the event the server is unable to return 
> capabilities information.
> Looking at the list in RFC 1893 I'd say one possibility is 
> x.3.3, system not
> capable of selected feature. I also note in passing that 
> there are no examples
> of CONNEG failures in the examples section. Some examples of 
> this sort need to
> be added.
> 
> Another interesting case that could arise in practice is 
> where a server is
> configured to require authentication, integrity, or privacy 
> services before
> capability information can be returned. I think the document 
> needs to discuss
> this case, saying that if such requirements have not been met 
> the CONNEG
> extension should not be offered in the EHLO response. (Note 
> that successful
> security negotiation already involves repeating EHLO.)
> 
> Although several examples of returned capabilities are shown, 
> the document
> isn't very specific about how capabilities have to be 
> formatted. In particular,
> I'd expect to see capabilities often stored as a single 
> string without any line
> breaks. Some advice on how to take such a string and format 
> it for inclusion in
> the reponse seems warranted.
> 
> According to this document the only capabilities that can be 
> returned are those
> defined in RFC 2879, which is FAX-specific. I realize this 
> document is a
> product of the FAX WG, but is this really appropriate? Should 
> more general
> capabilites return be allowed? And if not, shouldn't this 
> extension be called
> FAXCONNEG or something similar?
> 
> Finally, this document makes passing reference to "use in 
> relay scenarios". I
> think some elaboration of this might be in order. In 
> particular, I see at least
> two scenarios that involve relaying: One where a server knows it will
> subsequently relay the message but offers up capability 
> information by proxy,
> and another where the client is an intermediary service with message
> downgrading capabilities.
> 
> That's it!
> 
> 				Ned
> 

RE: AD review comments on draft-ietf-fax-esmtp-conneg-01.txt

> Thank you for your attention and feedback on
> draft-ietf-fax-esmtp-conneg-01.txt and previously
> draft-ietf-fax-tiff-fx-regbis-04.txt. There, however, appears to be some
> oversight as draft-ietf-fax-tiff-fx-reg-01.txt was last called at the same
> time or before these drafts yet it has not received any feedback.

That's because there was no feedback to give. This document is still on the
IESG's plate.

				Ned

Last Call: Guideline of optional services for Internet FAX Gateway to Informational

The IESG has received a request from the Internet Fax Working Group to 
consider Guideline of optional services for Internet FAX Gateway 
<draft-ietf-fax-gateway-options-05.txt> as an Informational RFC.  

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by June 24, 2002.

Files can be obtained via 
http://www.ietf.org/internet-drafts/draft-ietf-fax-gateway-options-05.txt

Last Call: A Simple Mode of Facsimile Using Internet Mail to Draft Standard

The IESG has received a request from the Internet Fax Working Group to
consider A Simple Mode of Facsimile Using Internet Mail
<draft-ietf-fax-service-v2-05.txt> as a Draft Standard. This document
will obsolete RFC2305, currently a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by June 24, 2002.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-fax-service-v2-05.txt

Implementation Report is available at:
http://www.ietf.org/IESG/Implementations/RFC2305-Implementation.txt

Last Call: Internet FAX Gateway Functions to Proposed Standard

The IESG has received a request from the Internet Fax Working Group to 
consider Internet FAX Gateway Functions 
<draft-ietf-fax-gateway-protocol-08.txt> as a Proposed Standard.  

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by June 24, 2002.

Files can be obtained via 
http://www.ietf.org/internet-drafts/draft-ietf-fax-gateway-protocol-08.txt

Last Call: Internet FAX Gateway Functions to Proposed Standard

The IESG has received a request from the Internet Fax Working Group 
to consider Internet FAX Gateway Functions 
<draft-ietf-fax-gateway-protocol-08.txt> as a Proposed Standard.  

The IESG plans to make a decision in the next few weeks, and 
solicits final comments on this action.  Please send any comments 
to the iesg <at> ietf.org or ietf <at> ietf.org mailing lists by June 24, 2002.

Files can be obtained via 
http://www.ietf.org/internet-drafts/draft-ietf-fax-gateway-protocol-08.txt