So, for example, the FAX number listed is the number that subscribers will
call if they want to fax something (say, a service request) _to_ the
provider. This is the provider's OWN fax number. The FAX is indeed going to
be far away from the roaming user 99.99% of the time. The number is NOT the
location of (e.g.) a kiosk FAX device.
+ Mark Anthony Beadles +
+ email@example.com +
+ Vox 614.565.1308 Pager 888.660.8427 +
[mailto:firstname.lastname@example.org]On Behalf Of email@example.com
Sent: Wednesday, 27 October 1999 10:55
To: Glen Zorn
Cc: Maximilian Riegel; firstname.lastname@example.org; Calhoun, Patrice;
Subject: Re: New internet draft:
Perhaps I am the one who misunderstands the overall purpose of the
"phonebook" or the context of it's use but I would say
1. OK... so it's the "only" fax number not the preferred one. So it's the
"only" printer not the preferred. (Typically, I see fax and print devices
scattered largely about in great multiplicity so I think this distinction
is minor... but I'll go with it)
2. The purpose of putting the printer URL is analogous to putting the FAX
number. Why would using the print URL irritate the ISP any more than using
the FAX machine? (Obviously, don't include a URL to your desktop printer if
you don't want remote jobs to land there).
3. The printer would not necessarily be far from the roaming user ... at
least no more so than the FAX machine. (Here, is where maybe my
understanding of the use of the "phonebook" is weak).
In general, my request for a print URL in addition to a FAX number reflects
the continued consolidation of device features where print, scan, copy,
local print, remote print, fax, e-mail are more frequently being
consolidated into a locale (device, kiosk or otherwise integrated
solution). I think it makes sense to accommodate this in the architecture
of your "phonebook".
IBM Printing Systems
Glen Zorn <email@example.com> on 10/26/99 05:28:26 PM
To: Harry Lewis/Boulder/IBM@IBMUS
cc: Maximilian Riegel <firstname.lastname@example.org>,
email@example.com, "Calhoun, Patrice" <firstname.lastname@example.org>,
Subject: Re: New internet draft: 'draft-ietf-roamops-phonebook-xml-02.txt'
On Tue, 26 Oct 1999 email@example.com wrote:
> Max, Glen... I would like to suggest you consider adding the "printer
> (ippURL?) to the list (below) of elements in the address book. This would
> indicate the URL for sending print jobs via the Internet Printing
> (see RFCs 2565, 2566 or the current Internet Drafts
> http://www.ietf.org/internet-drafts/draft-ietf-ipp-model-v11-04.txt ,
> http://www.ietf.org/internet-drafts/draft-ietf-ipp-protocol-v11-03.txt ).
> Pragmatically, it will allow the entry to reflect one's "favorite
> just as the current definition carries the preferred "fax number".
I'm confused. The FAX number below is not a "preferred" FAX #, it's the
_only_ FAX number for the provider. I'm not sure what the purpose of
putting a printer URL in the provider element would be (except maybe to
irritate ISPs by running jobs on the office printer ;-): the printer would
almost certainly be somewhere far from the roaming user.
> <!ELEMENT provider (
> supportPtr* )>
> <!ATTLIST provider
> id ID #REQUIRED>
> Harry Lewis
> IBM Printing Systems
> Maximilian Riegel <firstname.lastname@example.org> on 10/25/99 10:59:40
> To: email@example.com
> cc: "Zorn, Glen" <firstname.lastname@example.org>, "Calhoun, Patrice"
> Subject: New internet draft: 'draft-ietf-roamops-phonebook-xml-02.txt'
> I have send a new version of the phone book draft named
> 'draft-ietf-roamops-phonebook-xml-02.txt' to the IETF. It should
> appear on the list and in the archives in a few days.
> A comprehensive revision of the last draft was undertaken to fix the
> items mentioned in Oslo and on the mailing list. What's changed:
> - Addition of a introductory paragraph emphasizing the application of
> the phone book as standard format for exchanging information between
> providers and the roaming consortium as well as between the roaming
> consortium and the users.
> - Usage of XML attributes for several elements to achieve a more
> readable and compact representation of the phone book. In addition the
> assigned values of XML attributes can be syntactically checked by a
> XML Editor enforcing the compliance with the specification of the DTD
> (document type definition). Even more by putting the attribute
> definitions into a separate document and importing it by an external
> reference into the DTD, extensibility of the specification without
> modification of the basic DTD is achieved. This structure allows IANA
> to maintain the attribute value space of the phone book.
> - Refinements of several elements, e.g. the number of occurrences
> allowed for the elements in the setup element, or the predefined
> values for the attribute "type" of the "pop"-element "address" (former
> - Revision of the complete DTD according to the modifications
> introduced by this version.
> - Addition of a chapter "IANA considerations" (needs some more
> - Addition of a chapter containing simple examples of a roamops phone
> As always:
> Comments are kindly appreciated.