home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / fax / fax-minutes-97aug.txt < prev   
Text File  |  1997-10-10  |  13KB  |  355 lines
  1. Meeting Minutes - Internet Fax WG 
  2. 39th IETF, August 1997, Munich
  3.  
  4. Chairs:  James Rafferty, Dave Crocker
  5.  
  6. Minutes reported by:  Graham Klyne
  7.  
  8. 0. Agenda, goals, etc.
  9. ----------------------
  10. 1. TIFF Finalization
  11. 2. Service integration issues
  12. 3. News/relationship
  13. 4. Session mode SMTP proposal
  14.  
  15. 1. TIFF finalization
  16. --------------------
  17.  
  18. TIFF-F:  Tiny, core set, separate extension set
  19. TIFF-FX: Further extensions
  20.  
  21. (a) TIFF-F
  22.  
  23. Internet draft: Tag Image File Format (TIFF) - Application F
  24. <draft-ietf-fax-tiff-03.txt>
  25.  
  26. Changes in the latest revision are:
  27. - Defines application F of TIFF (aka TIFF-F)
  28. - Baseline TIFF 6.0 as starting point
  29. - Defines and specifies min subset of TIFF-F consistent with histrorical
  30. TIFF-F
  31. - Range of values for fields consistent with T.4/T.30 recommendations
  32. - TIFF overview moved to image/tiff (registration doc)
  33. - Clarified practice for readers and writers
  34. - Various editorial changes
  35. Intended as stable reference for TIFF-F.
  36.  
  37.  
  38. Internet Draft: Tag Image File Format (TIFF) - image/tiff
  39. MIME sub-type registration
  40. <draft-ietf-fax-tiff-reg-01.txt>
  41.  
  42. Defines MIME conent type "image/tiff"
  43.  
  44. Potential referrers are:
  45. - VPIM
  46. - Internet fax
  47. - ITU-T
  48. - WIDE
  49.  
  50. James Rafferty, regarding the relationship to WIDE:
  51. We now have new and more mature drafts for both TIFF-F (and -FX). 
  52. WIDE was using a different subset of TIFF. 
  53. It was agreed in Memphis that TIFF-F should include a 
  54. definition of a minimum set of TIFF features for Internet fax, 
  55. but WIDE defined a different minimum set.
  56. A meeting between TIFF-F and WIDE authors was held to try and 
  57. resolve these differences.
  58.  
  59. Issues:
  60. 1. differences in fields/values for WIDE vs "minimum" TIFF-F
  61. 2. differences between WIDE TIFF file structure and TIFF-F "guidelines"
  62.  
  63. Proposals for alignment:
  64. 1. Revise "minimum" TIFF-F values to satisfy WIDE requirements.
  65. 2. Revise WIDE to reference "minimum" TIFF-F using multi-page TIFF files
  66. (Subfiletype 2).
  67. 3. Maintain the principle that all Internet fax readers must read the
  68. "minimum" TIFF set.
  69.  
  70. Proposed changes to "minimum" TIFF-F:
  71. - Field T4Options: permit 0 in addition to 4 (byte aligned and non-byte
  72. aligned).
  73. - Field ImageWidth: keep 1728, delete 2048
  74.  
  75. *** Ageement:  The meeting consensus was to accept these proposals.
  76.  
  77. It was proposed to add one additional point to the current TIFF-F 
  78. recommended "guidelines" for reading/writing tiff files, for better
  79. consistency with WIDE:
  80.  
  81. This is to require the IFD to precede the related image. 
  82.  
  83. *** Agreement:  The meeting consensus was to accept the proposal.
  84.   
  85.  The WIDE authors propose a stricter ordering of:
  86.     header, IFD0, image0, IFD1, image1, ...
  87.  
  88. would be required for the case of writing a TIFF-F file
  89. which uses the minimum set of TIFF-F.   For the more general case, 
  90. the TIFF-F recommended "guidelines" will still apply.  
  91.  
  92. (The reason for this stricter ordering is to allow low-memory devices
  93. to receive fax images. Some other implementations have all IFDs at front)
  94.  
  95. Discussion:  
  96.  
  97. Steve Zilles:
  98. (a) will this break existing computer-based TIFF writers?
  99. (b) it is sometimes useful to put all IFDs at the front so that files
  100.  can be selectively byte-served.
  101.  
  102. (floor): experience suggests first page is wanted first.
  103. Zilles: but what do we want second?
  104.  
  105. Q: why do we want to do this change?
  106. A (Ritsuo Shirahama): in case of the paired format used by WIDE, the 
  107. amount of memory needed to process image is an absolute minimum, there
  108.  being no need to buffer IFDs.
  109.  
  110. Q: Has a survey of TIFF writers been conducted to determine whether or not
  111. they conform to this proposal?
  112. A: Existing TIFF-F writers have not been checked.  Readers have been checked.
  113. A (Neil Joffe?): some legacy TIFF writers put the IFDs at the end.
  114.  
  115. *** Agreement:  The consensus in the meeting was to adopt the WIDE 
  116. proposed ammendment (i.e. (i.e. the stricter IFD/image ordering will 
  117. apply when writing minimum TIFF-F files).
  118.  
  119. Question about RTCs: does WIDE include this? -- deferred to the list
  120.  
  121. (b) TIFF-FX
  122.  
  123. Internet draft: File Format for Internet Fax
  124. <draft-ietf-fax-tiffplus-01.txt>
  125.  
  126. Steve Zilles presented an overview of the latest draft on slides.
  127.  
  128. The goal is to achieve a set of nested file formats: TIFF-FX has been
  129. revised with this end in mind. The nesting consists of WIDE, TIFF-F and
  130. TIFF-FX, covering the following features:
  131.   WIDE:     MH (T.4) b/w
  132.   TIFF-F:   MMR (T.6) b/w
  133.   TIFF-FX:  JBIG (T.82) b/w halftones
  134.             T.42 JPEG (T.81) colour photo
  135.             T.43 JBIG (T.82) 'office' colour
  136.             T.44 MRC Mixes photo/office colour
  137.  
  138. Sect 2: this contains an introduction to TIFF and related Fax concepts, and
  139. may be moved to a separate MIME registration document.
  140.  
  141. Sect 2.2, fields for all applications: This has the agreement of the WIDE
  142. authors for defining a baseline feature set.
  143.  
  144. GlobalParametersIFD field is new
  145.  
  146. Sect 3: approx correspondence to WIDE, except:
  147. - BadFaxLines
  148. - CleanFaxData
  149. - ConsecutiveBadFaxLines
  150.  
  151. These are not required in minimum set (not usually applicable for
  152. Internet-carried fax)
  153.  
  154. The draft has been re-structured to better represent 
  155. the nested structure of minimum TIFF -> TIFF-F -> TIFF-FX (multiple modes).
  156.  
  157. Summary:
  158. The draft's current structure addresses:  
  159. (a) WIDE (minimum TIFF-F)
  160. (b) TIFF-F
  161. (c) ITU fax extensions
  162. It provides a common structure for the document parts relating to 
  163. these levels of functionality. 
  164.  
  165. Zilles suggested the document is ready to edit as a proposed standard.
  166. However, few people in the room had actually read the document.  The TIFF
  167. authors are directed to  
  168. complete the integration between TIFF-F and TIFF-FX in the TIFFPLUS
  169. document, while
  170. also incorporating the latest agreements from this meeting.
  171.  
  172. Q (Neil Joffe): Wants streamable file type for low-memory senders on the
  173. Internet.  What is the position of the TIFF-FX authors?
  174. A: The ordering proposals begin to address this.    MRC allows striping of
  175. data.  
  176. But there is a fundamental conflict between low-memory writer and 
  177. low-memory reader requirements in the context of the TIFF file structure.
  178.  
  179. Further discussion of this point was moved to the list as TIFF file 
  180. format changes will be needed to resolve low-memory reader/writer
  181. requirements conflict.
  182.  
  183. 2. Service integration issues
  184.  
  185. Presented by Dave Crocker, using the WIDE proposal document as a base for
  186. discussion.
  187.  
  188. The thrust of this part of the discussion was to present ideas which
  189. characterize a
  190.  user's perception of what constitutes a fax service, with a view to 
  191. evaluating the extent to which this perception can/should be satisfied by a 
  192. version 1.0 proposed Internet fax standard.  
  193.  
  194.  
  195. (a) Service goals
  196. - Fax emulation -- within reason (fax service emulation, not fax protocol
  197. emulation)
  198. - Store and forward (asynchronous, not user-observed delivery)
  199. - Integrate fax and email user bases
  200. - Use of Internet mail technical base in "natural" fashion. A profile of
  201. classic Internet email for use as fax transport.
  202.  
  203. (b) Addressing
  204.  
  205. Requirements:
  206. - Can reply to message
  207. - Can use with mailing lists
  208. Leads to requirement that address is not in message body.
  209. - Subaddressing
  210. This is a somewhat recent ITU feature, which is showing up suprisingly
  211. quickly in the installed base.  This suggests that any Internet fax address
  212. syntax must be able to represent sub-addressing.  Sub-addressing is use of
  213. address information in addition to the base telephone number to target a
  214. specific recipient.
  215. **** There is a need to discuss, on the mailing list, the issue of multiple
  216. sub-addresses "to the same destination".
  217. - Syntax which explicitly identifies an address as a fax number?
  218. - Form of telephone phone number to be used?
  219. Q (Dan Wing?): Should we follow VPIM spec wrt addressing?
  220. A (DC): Yes (in narrow and wide senses)
  221.  
  222. Email address candidates:
  223. - Number as mailbox? (user-based knowledge for network routing)
  224. GK: this form can also be used for network-based routing knowledge.
  225. - Number in service name? (network-based routing knowledge)
  226. WIDE proposal:
  227. - 12345-67890@domain
  228. Steve Patterson
  229. - +12345678901@domain
  230.   Q: use some kind of explicit fax type label?
  231.   George Pajari has commented on the mailing list that there is not always
  232. a country code in a telephone number.
  233. - "Pause" ("-") duration - should be specified?
  234. - how does gateway process the number wrt its own location, etc.
  235. Larry Masinter - pattern proposal posted to mailing list.
  236.  
  237.  
  238. (floor): what is the end-users' problem that we are trying to solve? --
  239. this should guide our discussion.
  240.  
  241. Claudio Allochio will post to the list a description which shows the
  242. consequences of different choices of address format.
  243.  
  244. **** Continuing discussion is moved onto the list.
  245.  
  246. (c) Reliability/acknowledgements
  247.  
  248. E-mail now has DSN, semantically equivalent to fax message confirmation (MCF).
  249.  
  250. Also under way is notification of a message being processed by its
  251. recipient (e.g. read).
  252.  
  253. E-mail has no re-transmission concept (in absence of confirmation) -- same
  254. as fax.
  255.  
  256. Issue of when confirmation should be sent by gateway:  when gateway
  257. receives message? when gateway receives confirmation? What about multiple
  258. gateway chains?
  259. - Experience with s/f fax indicates that having fax confirmation decoupled
  260. (delayed) from original call must be an end-to-end confirmation, or
  261. troubles result. (But where is the "end".)
  262.  
  263. **** Agreement:  The group in the meeting supported the idea that
  264. confirmation should be sent when it arrives at final mailbox or fax machine."
  265.  
  266. Should use of DSN be required?
  267. - sending from email: selection of DSN notification request is by user.
  268. - sending from a fax, use of DSN notification request might be:
  269. (a) user chooses?, or
  270. (b) DSN use is mandatory?, or
  271. (c) implementation dependent choice?
  272. There was a feeling in the room that this was an implementation issue.
  273. DC:  language is needed in the specification to explain this issue, without
  274. saying whether or not DSN is mandatory, but defining the fashion in which
  275. it must be used if it is used at all.
  276.  
  277. **** Issues of who pays the cost of providing a confirmation callback and
  278. the issue that callback may not be possible (due to lack of return path
  279. information) should be discussed on the mailing list.
  280.  
  281. (d) Security [[[and identification]]]
  282. Identification - label without authentication
  283. Authentication - "of undisputed origin".
  284. Integrity - usually for free with authentication.
  285. Privacy - proof against snooping.
  286. Authorization to use service (Denial of service protection?)
  287.  
  288. Larry: FROM of email to correspond roughly to required content of fax
  289. identification header line (per US law).
  290. DC: proposed that identification behaviour be provided equivalent to fax
  291. identification behaviour, but no strong cryptography requirement for
  292. authentication, etc.
  293. (floor): Need to identify sending fax machine for purposes of sending
  294. notification back.
  295. DC: On-ramp may need to adjust the FROM:, TO:, SENDER:, and other fields to
  296. get notification to work properly.
  297. (Some speculation about likely legal requirements for identification, ref.
  298. US requirement for all faxes to identify sender).
  299. Identification: there are difficult issues need to be addressed.
  300.  
  301. A call was made for information about range of legal requirements of
  302. identification in different regions to be posted to the list.
  303.  
  304. DC, Privacy over the Internet:  The Internet is perceived as not secure and
  305. easily tapped.  Therefore the Internet should be assumed to be less secure
  306. that telephone system, and therefore IF we are to emulate perceived current
  307. fax security THEN we must implement encryption of message data over the
  308. Internet, or some other privacy mechanism (e.g. control the path).
  309. JR: the user will make the choice.
  310. DC: suggested that the authentication and privacy issues would need to be
  311. considered in any fax standard, but would probably not be fully specified
  312. by this working group.
  313. **** Further discussion will take place on the mailing list.
  314.  
  315.  
  316. Authorization:
  317. DC: There is currently no widely-used Internet standard for authorization.
  318. Steve Zilles: Authorization to use the service consists of two separate
  319. issues:
  320. (a) mechanisms to control access to the facilities provided, given the
  321. identity of a party who is trying to use them, and
  322. (b) mechanisms to verify the identity of a party who is trying to use them.
  323. Issue (a) must be dealt with within the service protocol, but issue (b)
  324. could be handled by reference to some external authentication  mechanism.
  325.  
  326. DC: may pay attention to security without necessarily solving it. Need to
  327. explore very wide range of issues related to security, and interactions
  328. between them.
  329.  
  330. No specific consensus was reached by the meeting.
  331.  
  332. **** Further discussion is moved to the list.
  333.  
  334. 3. News
  335.  
  336. No time available
  337.  
  338. 4. Session service
  339.  
  340. No time available
  341.  
  342.  
  343. Closing presentation: Relation to ITU work. 
  344.  
  345. James Rafferty briefly summarized the relation of the IETF work 
  346. to that ongoing in ITU.  He noted that some ITU members have 
  347. expressed interest in using TIFF-F for store and forward fax via 
  348. e-mail.  Some of the current IDs, notably on TIFF, are likely to be
  349. submitted to the 
  350. October ITU SG8 meeting.   Cross reference between ITU and IETF documents 
  351. is now permitted, so this would provide a way for ITU to incorporate 
  352. IETF work (and vice versa) and reduce the chance of producing conflicting
  353. standards.  
  354. Continued communication and cooperation between the two standards bodies is
  355. desirable.