Subject: [nfsv4] re: Owner and Group strings

From: [email-masked]
Date: Tue, 2 Mar 2004 13:00:25 -0500 (EST)

> > (A non-POSIX style client might just always display Owner verbatim and
> >  the user/sysadmin might understand the "internal string" that gets
> >  displayed?)
> 
> [Nico wrote]
> I'm not aware of any major OS platform which deals in "external"
> identifier forms, rather than internal identifier ones, in its APIs.

I was not thinking of an OS client. Something more along the lines of
a web browser that chooses to list the contents of a "public" NFS
volume.

rick

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 Mar 2004 12:26:17 -0600

And I addressed that as well:

> And if there were any such [platforms] a server that uses stringified
> numbers on the wire as IDs would merely confuse the _user_ instead of
> the client.  The end result would be the same: not useful.

This applies just as much to user-level NFSv4 client implementations
that do no mapping of user/group names.

I suppose that for _some_ users seeing numbers [that would be
meaningless to most other users] could be useful.

But would that be worth it when most clients would be unable to map the
numbers anyways?

RFC3530 provides for name@domain user/group ID forms on the wire for
good reasons.  We should encourage all implementors to implement support
for this wherever possible.  Of course, some implementations may be
limited to a single domain of users/groups.

Light-weight server implementations may have a hard time mapping names
to internal identifiers, but if using stringified integers on the wire
is useless anyways, then maybe such light-weight servers should just not
support the ACL attribute.

Cheers,

Nico
--