From owner-ietf-cat-wg@lists.Stanford.EDU Wed Aug 11 17:57:43 1999
Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07628
for ; Wed, 11 Aug 1999 17:57:42 -0400 (EDT)
Received: (from daemon@localhost)
by lists.Stanford.EDU (8.9.3/8.9.3) id OAA27467
for ietf-cat-wg-out720680; Wed, 11 Aug 1999 14:13:58 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id OAA27461
for ; Wed, 11 Aug 1999 14:13:55 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA14123;
Wed, 11 Aug 1999 14:13:49 -0700 (PDT)
Received: from taller.eng.sun.com (taller.Eng.Sun.COM [129.144.123.34])
by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id OAA15336;
Wed, 11 Aug 1999 14:13:48 -0700 (PDT)
Received: from vishwas.eng.sun.COM by taller.eng.sun.com (SMI-8.6/SMI-SVR4)
id OAA26529; Wed, 11 Aug 1999 14:13:46 -0700
Date: Wed, 11 Aug 1999 14:13:55 -0700 (PDT)
From: Mayank Upadhyay
Reply-To: Mayank Upadhyay
To: "Linn, John"
cc: "'CAT-WG List'"
Subject: Java GSS ChannelBindings: Apple Mac and IPv6
In-Reply-To:
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-cat-wg@lists.Stanford.EDU
Precedence: bulk
On Thu, 29 Jul 1999, Linn, John wrote:
> An issue arises for channel bindings, as Java doesn't support non-Inet
> addresses. Peers could, however, agree to insert non-Internet addresses
> themselves in an externally specified format. As an alternative, the
> current definition could be modified, defining 22 static constants for
> different address types analogous to those defined in the GSS C bindings.
> It was unknown whether any existing implementations interpret channel
> bindings for non-Inet address types. It was also believed that few if any
> non-IP GSS apps exist, though Appletalk might be an exception.
I have been unsuccessful in finding any implementations of the GSS-API for
the Mac on the web. If any Apple developers on the alias have more
information on this I would be grateful if they could mail the alias. I
am interested in determining if Java applications for the Mac that want
GSS-API support would also probably use Java's InetAddress class and
TCP/IP sockets. I could not find an alternative networking Java API for
the Mac. If this is how it is, then we don't have a problem with using
InetAddress as far as the Mac is concerned.
> Ted Ts'o
> asked whether the current approach would support IPV6 and interoperability
> between C and Java GSS implementations for either IPV4 or IPV6. It appeared
> that Java needs an extensible address class (including both IPV4 and IPV6,
> even though not non-Internet address forms), which Jeff Schiller (MIT)
> believes it has.
Most probably the InetAddress class will represent both v4 and v6
addresses. I checked with some of the implementors here at Sun who
confirmed this opinion. Some new methods `might' be added to it to
indicate which one of the two an instance represents.
InetAddress.getAddress() and InetAddress.getHostAddress() will behave
differently for IPv4 and IPv6 addresses.
> Question: does the Java equals method compare Ipv4 and
> Ipv6 addresses correctly? Some further Java research is needed here.
The answer to this question is, probably not. And this might be consistent
with its current behaviour wrt IPv4. Right now the equals method deems
two IPv4 addresses to be the same only when it succeeds in a comparison of
the raw bytes representing the two addresses. If one took two different
interfaces on a host, whether from the same or different address families,
and tried equals with them, it would not work because the two IP addresses
are not the same. (However, it might be desirable for the equals method to
correctly compare an IPv4 address to an IPv4 mapped IPv6 version of the
same address by stripping out the leading "0:0:0:0:0:FFFF". But this is
something to address when IPv6 support gets added to the JDK.)
-Mayank
==========================================================================
This message was posted through the Stanford campus mailing list
server. If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu
From owner-ietf-cat-wg@lists.Stanford.EDU Thu Aug 12 18:49:04 1999
Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23454
for ; Thu, 12 Aug 1999 18:49:04 -0400 (EDT)
Received: (from daemon@localhost)
by lists.Stanford.EDU (8.9.3/8.9.3) id PAA29841
for ietf-cat-wg-out720680; Thu, 12 Aug 1999 15:16:53 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id PAA29830
for ; Thu, 12 Aug 1999 15:16:49 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA15211
for ; Thu, 12 Aug 1999 15:16:48 -0700 (PDT)
Received: from taller.eng.sun.com (taller.Eng.Sun.COM [129.144.125.34])
by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id PAA01596;
Thu, 12 Aug 1999 15:16:47 -0700 (PDT)
Received: from vishwas.eng.sun.COM by taller.eng.sun.com (SMI-8.6/SMI-SVR4)
id PAA16504; Thu, 12 Aug 1999 15:16:47 -0700
Date: Thu, 12 Aug 1999 15:16:55 -0700 (PDT)
From: Mayank Upadhyay
Reply-To: Mayank Upadhyay
To: ietf-cat-wg@lists.Stanford.EDU
cc: "Michael R. Eisler"
Subject: Java GSS: Major status codes and exceptions
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-cat-wg@lists.Stanford.EDU
Precedence: bulk
On Thu, 29 Jul 1999, Linn, John wrote:
> .... A GSS-level question arises here, which John
> Linn plans to investigate: in what (if any) combinations are different major
> status codes conformantly permitted to exist in conjunction with one
> another?
This was a concern about the exception model raised by Mike Eisler at the
Oslo meeting. Included below is my interpretation of what 2078bis and the
C bindings document imply about this matter. John Linn asked me to
forward this to the alias to confirm it. Please reply if you disagree.
Thanks,
Mayank
----------
We don't have an explicit mechanism to return two major status codes
simultaneously in Java GSS but we dont need it either based on the
requirements in the RFC.
2078bis only mentions the sequencing related status codes (GAP_TOKEN,
DUPLICATE_TOKEN, etc ) as potentially being returned in conjunction with
one of COMPLETE or FAILURE. Morevoer, it mentions that during context
establishment a sequencing problem is always fatal and must be returned
with FAILURE whereas during the per-message calls the implementation can
return the sequencing status code with either COMPLETE or FAILURE. The
java bindings still allow the same thing to be achieved, although
differently.
If the implementation wishes to return a sequencing state that is a
fatal error, it throws an exception with this sequencing error code
contained within the exception.
If the implementation wishes to return a sequencing state that is
not a fatal error, but just informatory, then it does so in the
MessageProp structure associated with the per-message call.
Hence indicating a second COMPLETE/FAILURE code along with the sequencing
code is unnecessary.
Note that the "calling errors" defined in the C bindings are not an issue
in the Java platform. They are optional even within that document and may
be returned in some other platform specific way. Java has stronger type
checking when passing objects around and also has exceptions defined for
invalid parameters.
----
==========================================================================
This message was posted through the Stanford campus mailing list
server. If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu
From owner-ietf-cat-wg@lists.Stanford.EDU Thu Aug 19 04:26:24 1999
Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20198
for ; Thu, 19 Aug 1999 04:26:24 -0400 (EDT)
Received: (from daemon@localhost)
by lists.Stanford.EDU (8.9.3/8.9.3) id AAA14182
for ietf-cat-wg-out720680; Thu, 19 Aug 1999 00:54:29 -0700 (PDT)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id AAA14176
for ; Thu, 19 Aug 1999 00:54:26 -0700 (PDT)
From: pplegal@hotmail.com
Received: from mx1.magmacom.com by MIT.EDU with SMTP
id AA22349; Thu, 19 Aug 99 03:54:23 EDT
Received: from mail3.magma.ca (mail3.magma.ca [206.191.0.221])
by mx1.magmacom.com (8.9.1a/8.9.1) with ESMTP id DAA05955;
Thu, 19 Aug 1999 03:53:39 -0400 (EDT)
Received: from cyberblitz.com (harris.magma.ca [209.217.80.7])
by mail3.magma.ca (8.9.3/8.9.3) with ESMTP id DAA19530;
Thu, 19 Aug 1999 03:53:37 -0400 (EDT)
Received: from 160.92.127.3 (01-024.033.popsite.net [216.3.182.24])
by cyberblitz.com (8.9.1/8.9.1) with SMTP id DAA07947;
Thu, 19 Aug 1999 03:58:33 -0400 (EDT)
Message-Id: <000013075d12$00003af4$00005625@160.92.127.3>
To:
Subject: MAKE $100,000 PER YEAR & UP WITH NEW PERSONAL POSTCARDS
Date: Thu, 19 Aug 1999 03:43:34 -0400
Mime-Version: 1.0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-Msmail-Priority: Normal
Sender: owner-ietf-cat-wg@lists.Stanford.EDU
Precedence: bulk
Content-Transfer-Encoding: quoted-printable
The Hottest Bus=
iness Opportunity to Hit
the U.S. this Year!=
B>
This is not a MLM =
Program !
Earn Full Time Inc=
ome on a Part Time Basis !!!
New Photo Postcard vending machines which put you=
r face on a postcard
are a smashing success throughout Europe.
Now for the first time these machines are ava=
ilable in the U.S.
The U.S. market will grow to thousands of machines within the next
12-18 months according to industry experts. We are seeking qualified indiv=
iduals
who are looking to take advantage of a virtually untapped market opportuni=
ty in
their area. There are retail locations across the country ......waiting ! =
Timing is Everything !
We have developed the new self-service Personal P=
ost Card to take advantage
of this dynamic market opportunity. Personal Post Cards combines the popul=
arity
of the following markets:
Travel and Leisure Ma=
rket $200 billion
Greeting Card $10 bil=
lion
Photography $30 billio=
n
The Opportunity Is:
Part or full time
No selling required
No prior experience or=
office required
All cash business!
Financing programs ava=
ilable
For a Free Business Package at N=
o Obligation:
1-888-852-7900
Please refer to Code F818 when you call.
Customer Service Opera=
tors are available
Monday-Friday 9:00am - 9:00pm EST Saturday-Sunday 12:00 pm to 8 pm EST.
If you are outside the U.S. please fax your name, complete phone number
including country code and a good time for us to call you to (954)236-7264=
.
We will respond to your request as soon as possible.
This offer is not vali=
d in all statesand should not be considered an offer
in states where the company is not registered.
If you no longer desir=
e to receive email from us, please email us,
CLICK HERE.
The Hottest Bu=
siness Opportunity to Hit
the U.S. this Year!