On Thu, 1 Apr 1999 13:04 -0500, FREE-FAX New York wrote: > If you want to send IFaxes via email, get something that's designed to > do the job. I can't control the software installed by the readers of the ietf-fax <at> imc.org mailing list -- which is how I received my Blast >From the Past. -Dan Wing
> Some time ago, there was some discussion about how to proceed with > identification of primary message content. Some have suggested that > alternatives to those indicated in <draft-ema-vpim-um-01.txt> should be > considered. I thought that people were leaning toward just adding a different content-disposition inside some parts of multipart that indicated that some parts were optional, and then noting that MDNs for multiparts shouldn't note that the message was "read" unless all of the parts were "read". > I am wondering if these discussions have been progressing at all behind the > scenes. Or just in a different scene. > There is one Internet fax related proposal on the table, and another > waiting in the wings, for dealing with message-related issues that are > dependent on the direction taken for the message primary content proposal, > so I would be very keen to hear how this is progressing. I dislike the proposal in draft-ema-vpim-um-01.txt, since it defines the "primary type" by the media type rather than just noting which parts of a multipart are critical. I also think it's important to note that often the desire is to confirm processability rather than actual 'read' status. I also disagree with the characterization:(Continue reading)
At 08:32 03/05/99 PDT, Larry Masinter wrote: >> There is one Internet fax related proposal on the table, and another >> waiting in the wings, for dealing with message-related issues that are >> dependent on the direction taken for the message primary content proposal, >> so I would be very keen to hear how this is progressing. > >I dislike the proposal in draft-ema-vpim-um-01.txt, since it defines >the "primary type" by the media type rather than just noting which >parts of a multipart are critical. I also think it's important to note >that often the desire is to confirm processability rather than actual >'read' status. I understood there to be two purposes to that proposal: (a) to indicate the primary media type for dispatching purposes (e.g. to prefer presentation via telephone handset or computer terminal). (b) to indicate the critical parts of the message. I also see a third, and less obvious, value in the proposal: (c) a framework that can indicate the presence of message-related semantics as opposed to an arbitrary data resource. The value of this aspect is not clear, but an example that suggests possible utility is the form of Mike Ruhl's cover page proposal. >I also disagree with the characterization: > > Recently, email(Continue reading)
Hello! You have been invited by sunetong to join the Listed Yahoo! Club named "Internet Fax". To become a member of this club, just go to the Web address below: http://edit.clubs.yahoo.com/config/sjg?.k=EB337321a86uMLEC You need to go to the address above to join the club, but you can take a look at the club by going to: http://clubs.yahoo.com/clubs/internetfax You can learn more about sunetong by looking at the Yahoo! Public Profile: http://profiles.yahoo.com/sunetong Note: This invitation will expire after 7 days, or after being used. A Yahoo! Club is a great way to bring friends, family or anyone you know together using the latest in Web technologies. Club members are able to take advantage of a club's private chat room, message boards and other features. You can also create your own free club focused on any interest, such as hobbies, families and industry associations. Clubs are either listed or unlisted. Listed clubs are available to the public while unlisted clubs are(Continue reading)
This is the Working Group last call notice for the following draft: >Title : GSTN address element extensions in e-mail services >Author(s) : C. Allocchio >Filename : draft-ietf-fax-fulladdr-06.txt >Pages : 23 >Date : 26-Apr-99 > >The possible elements composing a 'Global Switched Telephone Network >(GSTN) address in e-mail' (formerly known also as Public Switched >Telephone Network - PSTN) can vary from a minimum number up to a >really large and complex collection: the minimal format and general >address syntax are defined in [1], together with the syntax to define >additional address elements. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-fax-fulladdr-06.txt This document has been under review in the WG and in other communities interested in telephony address elements during the past year. At our last IETF meeting, it was felt that the document was stable, excepting the need to finalize the IANA considerations and registrations. The main revision since the last IETF meeting has been to add an IANA registration section for various GSTN address elements as they will appear on the left side of email address. I am also ccing the VPIM list, since they are working on documents which reference this draft.(Continue reading)
Folks, This is a followup to my report on the ITU-T Study Group 8 meeting that was held in March and April. At that time, the final status of the proposed Amendment 1 to ITU-T T.37 was on hold, pending a 4 week review period by two countries, the United States and Germany. The proposed amendment adds text to T.37 which defines the "Full Mode" for store and forward Internet fax, via reference to the new IETF Internet fax RFCs (RFC 2530-2532) and some older RFCs (for DSN, MDN and ESMTP). An ITU "decision" on a document requires unanimous consent for approval. As it turns out, after a review conducted during this 4 week period, Germany has voted No. The US vote is a conditional Yes (requesting that text be added to T.37 clarifying that embedded references in IETF RFCs listed as "Work In Progress" are not normative). So, the net result of this review process is that the amendment 1 to T.37 does not pass at this time. Per my understanding, the next SG8 meeting at which the amendment could be approved (with minor corrections as applicable), is to be held early next year. In the remainder of this note, I will offer my perspective on what happened and why, and also discuss where the IETF Fax WG and the ITU Q4 can go from here to complete this approval process. I personally believe that this result is unfortunate for the marketplace, since a joint IETF and ITU endorsement of new standard approaches carries(Continue reading)
To all - A question came up on the TIFF-FX specification, RFC 2301 during the Fax Connect II testing today. In section 2.2.2, there is text under the definition of fill order that says that all TIFF readers must be able to read both bit orders. However, Profile S only requires support for the LSB first bit order (value =2 ) and this is stated in two places within that section (3) of RFC 2301. The agreement reached in the WG was that Profile S does have some constraints that the other profiles do not have, including this restriction of a single permitted bit order. This will require a correction to the text of the updated draft for the RFC (draft-ietf-fax-tiff-fx-00.txt Regards, James *------------------------------------------------* James Rafferty President, Human Communications LLC 12 Kevin Drive Danbury, CT 06811-2901 USA Voice/Fax: +1-203-746-4367 Email/Internet Fax: JRafferty <at> worldnet.att.net(Continue reading)
James, Thanks for bringing this to my attention. I will make the appropriate changes to the text of the TIFF-FX spec (draft-ietf-fax-tiff-fx-00.txt). Rob -----Original Message----- From: James Rafferty [mailto:jrafferty <at> worldnet.att.net] Sent: Wednesday, May 19, 1999 6:43 PM To: Ietf-Fax Cc: Dennis Venable; Glenn Parsons; Lloyd McIntyre; Buckley,Rob R; Steve Zilles Subject: TIFF-FX clarification To all - A question came up on the TIFF-FX specification, RFC 2301 during the Fax Connect II testing today. In section 2.2.2, there is text under the definition of fill order that says that all TIFF readers must be able to read both bit orders. However, Profile S only requires support for the LSB first bit order (value =2 ) and this is stated in two places within that section (3) of RFC 2301. The agreement reached in the WG was that Profile S does have some constraints that the other profiles do not have, including this restriction of a single permitted bit order.(Continue reading)
Hallo all, after reading both drafts I would suggest to integrate them in one single document and proceed with its submission to the appropriate discussion groups. In particular, draft-antti-sms-service-selector-00.txt is more detailed as it is based on the full addressing specification. During the docs merging, you could also all sign the resultant doc. Regards Claudio Allocchio
Hello all, This is exactly the reason why I have not submitted the newer version of the "Minimal SMS address format in Internet Mail", which covers those issues. We have already agreed with Antti on the preparation of a single specification document. Regards, Nikolaos > > Hallo all, > after reading both drafts I would suggest to integrate them in one single > document and proceed with its submission to the appropriate discussion > groups. > > In particular, draft-antti-sms-service-selector-00.txt is more detailed > as it is based on the full addressing specification. > > During the docs merging, you could also all sign the resultant doc. > > Regards > Claudio Allocchio
RSS Feed1 | |
|---|---|
4 | |
7 | |
2 | |
1 | |
1 | |
1 | |
15 | |
5 | |
6 | |
4 | |
35 | |
13 | |
2 | |
1 | |
7 | |
5 | |
2 | |
2 | |
1 | |
6 | |
16 | |
11 | |
11 | |
12 | |
9 | |
25 | |
3 | |
38 | |
28 | |
23 | |
25 | |
18 | |
214 | |
22 | |
3 | |
17 | |
53 | |
14 | |
26 | |
47 | |
28 | |
19 | |
21 | |
76 | |
61 | |
48 | |
26 | |
11 | |
152 | |
95 | |
16 | |
18 | |
44 | |
34 | |
18 | |
26 | |
58 | |
20 | |
34 | |
34 | |
61 | |
23 | |
35 | |
11 | |
12 | |
51 | |
28 | |
24 | |
22 | |
62 | |
14 | |
29 | |
64 | |
71 | |
34 | |
33 | |
64 | |
132 | |
115 | |
103 | |
289 | |
257 | |
176 | |
24 | |
104 | |
40 | |
164 | |
369 | |
248 | |
97 | |
260 | |
106 | |
116 | |
94 | |
359 | |
165 | |
61 | |
33 | |
244 | |
267 | |
159 | |
37 | |
96 | |
35 | |
6 |
