Subject: Re: [FAX] Status of WG Last Call on -eifax

From: Graham Klyne <[email-masked]>
Date: Sun, 11 Oct 1998 21:10:01 +0100

At 10:36 09/10/98 -0400, James  Rafferty wrote:
[...]
>
>However, there are still a few open items, mainly related to 
>references, so I would like to extend the WG Last Call comment period until
>this Friday, October 9, in the hope we can get them resolved soon.  

>1)  Section 2.1
>
>>2.2.   Recipient Requirements
>>
>>   Recipients in compliance with this document SHOULD implement MDN
>>   [RFC2298], and SHOULD implement Offramp Gateway Extensions for DSN
>>   and MDN [REPORT-EXTENSIONS].

Nit:  I notice that here, this is [REPORT-EXTENSIONS], but later it is
[REPORTING-EXTENSIONS]

>2)  Section 2.2.2
>
>There have been comments received on the second sentence here; 
>a tightened up version has been suggested by Ned Freed.   This text
>just serves to clarify normal behavior for email recipients.  
[...]
>Proposed revised text for second sentence:  
>
>>   The recipient MUST NOT use RFC822 "To:" fields, "Cc:" fields,
>>   "Bcc:" fields, or any other fields containing header recipient
>>   information to determine the ultimate destination mailbox or
>>   addressee, and SHOULD NOT use other RFC822 or MIME fields for
>>   making such determinations.

I think this is about right.

#g

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

---

From: Graham Klyne <[email-masked]>
Date: Thu, 15 Oct 1998 23:17:07 +0100

At 14:09 14/10/98 -0400, James  Rafferty wrote:
[...]
>"Extended Internet fax systems SHOULD/MUST (?) be able to recognize and
>process the feature tags as defined in [SCHEMA] when reviewing the
>capabilities presented for a potential Internet fax recipient, but should
>ignore any additional capabilities tags which it does not understand."    
>
>
>So, the first part of this sentence specifies a minimum requirement on the
>need for extended Internet fax systems to be able to recognize and process
>the tags defined in [SCHEMA].
[...]
>The second part of the sentence is intended to allow for the possibility
>that there may additional tags which are registered in the future, but were
>not in the original schema draft.   Existing systems will have to ignore
>the new tags.   

I've made this comment elsewhere, but I can't remember if it was public...

I think the conneg feature set matching rules already allow for the
extensibility you require, and simply ignoring unrecognized tags might
cause some problems.  So, I would suggest something more like this:

#    A sender SHOULD be able to recognize and process the feature
#    tags as defined in [SCHEMA] when reviewing the capabilities 
#    presented by a potential recipient.  The capability matching rules
#    indicated there (by reference to [CONNEG-FEATURE-SYNTAX]) allow for
#    introduction of new features that may be unrecognized by older
#    implementations.

#g

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