Brian Rosen wrote:
> Works for me. So you really want nick domain.
> I try to separate what is displayed from what the
protocol conveys.
> nickdomain is unique, can be persistent, and I don't see
any problem there.
> Certainly, it's no stretch to have
chatroom6.example.com as the domain.
>
> bobexample.com and bobatlanta.com can be
displayed as Bob(1) and Bob(2),
> or any other way the UI wants to.
Yeah, that's what I was thinking.
Paul
> Brian
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivatcisco.com]
>> Sent: Friday, May 18, 2007 10:17 AM
>> To: Brian Rosen
>> Cc: 'Gonzalo Camarillo'; 'Hisham Khartabil';
'SIMPLE mailing list'
>> Subject: Re: [Simple] MSRP chat: SIP-based nickname
negotiation
>>
>>
>>
>> Brian Rosen wrote:
>>> Gonzalo
>>>
>>> I don't want an MSRP specific solution. I
don't want an XCON solution.
>> I
>>> want a SIP/IM/Presence/XCON... solution.
Nicknames are a common thing.
>> Right.
>>
>>> The most common nicknames are things like AOL
screen names. They are
>>> persistent, unique within a domain, and used
with all forms of
>>> communication.
>> I agree with what you say here about the prior art.
But I have
>> difficulty relating the "unique within a
domain" part to what we are
>> doing.
>>
>> That works for AOL because all communications, even
the point to point
>> kind, are mediated by a server in the AOL domain.
Both ends share that
>> domain and so the nickname namespace.
>>
>> That fits with what the current proposal is,
because it applies only to
>> conferences, where again there is a common server
mediating all
>> communications.
>>
>> But it doesn't generalize to the broader scope that
you and I aspire to.
>> In particular it doesn't generalize to point to
point communications.
>>
>> The real world is also more complex than this when
you get to multiple
>> providers. For instance I use a Gaim IM client,
with connections to AOL
>> and to a corporate Sametime server. The namespace
for
>> nicknames/screen-names is separate for the two
domains but must be
>> resolved in the client UI.
>>
>> IMO the general solution must tag nicknames with
their domain. That
>> isn't so friendly if the domain shows up in the UI,
but neither is it
>> awful. It can be made better by a UI that does
defaulting of the domain
>> part of the nickname in a reasonable way.
>>
>> Paul
>>
>>> Per chat temporary nicks happen to us techies
that use
>>> things like IRC, not to the real world.
>>>
>>> I think this is a simple problem, with simple
solutions. I think it's
>>> reasonably a SIMPLE problem, with possibly some
SIP work for a header.
>> I
>>> think we can first apply it to MSRP chat and
expand it to XCON.
>>>
>>> The proposal on the table needs only a little
work, I think, to make it
>>> generally useful. I do think we need to agree
on requirements first,
>> but we
>>> seem to be coalescing fairly rapidly on that.
>>>
>>> Brian
>>>
>>>> -----Original Message-----
>>>> From: Gonzalo Camarillo
[mailto:Gonzalo.Camarilloericsson.com]
>>>> Sent: Friday, May 18, 2007 5:57 AM
>>>> To: Hisham Khartabil
>>>> Cc: Brian Rosen; SIMPLE mailing list
>>>> Subject: Re: [Simple] MSRP chat: SIP-based
nickname negotiation
>>>>
>>>> Hi,
>>>>
>>>> regarding the scope of this work, my
understanding was that SIMPLE was
>>>> going to come up with an MRSP-specific
solution for nicknames. A
>> general
>>>> solution for nicknames would be developed
by XCON (SIP might be to be
>>>> involved as well if SIP extensions were
needed) at a later stage.
>>>>
>>>> Therefore, the only requirement on the
MSRP-specific solution would be
>>>> that it is future-proof so that it does not
keep us from developing a
>>>> more general (while being backwards
compatible) one in the future.
>>>>
>>>> If my understanding of the process is
correct, let's get the
>>>> MSRP-specific solution finished and let's
discuss the more general one
>>>> somewhere else (e.g., XCON). If, on the
other hand, this is not the
>>>> process we want to follow, I would
appreciate if somebody could clarify
>>>> what our plan is.
>>>>
>>>> Thanks,
>>>>
>>>> Gonzalo
>>>>
>>>>
>>>>
>>>>
>>>> Hisham Khartabil wrote:
>>>>> Brain,
>>>>>
>>>>> Thats fair enough. Why don't you get
with Miguel and Aki and add some
>>>>> text to the draft that makes it a
generalised mechanism. I believe
>>>>> Miguel are Aki are more than happy to
make you a co-author of this
>>>>> draft.
>>>>>
>>>>> Hisham
>>>>>
>>>>> On 17/05/07, Brian Rosen <brbrianrosen.net> wrote:
>>>>>> Hisham
>>>>>>
>>>>>> Do you think it would be wise for,
let's say, a presence system which
>>>>>> uses
>>>>>> nicknames have a different
mechanism for informing its service of its
>>>>>> nickname than it would use for an
IM chat?
>>>>>>
>>>>>> Should the XCON mechanism be
different?
>>>>>>
>>>>>> I don't want to make this into a
big deal, but nicknames are not
>>>>>> peculiar to
>>>>>> IM chat. I don't want an IM chat
specific solution, especially when
>> I
>>>>>> don't
>>>>>> think we need a whole lot more than
is proposed. I think we need
>> SOME
>>>>>> more
>>>>>> to make a generalized nickname
feasible. Persistent nicks within a
>>>>>> domain
>>>>>> is one of the big differences.
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Hisham Khartabil
[mailto:hisham.khartabilgmail.com]
>>>>>>> Sent: Thursday, May 17, 2007
2:26 AM
>>>>>>> To: Brian Rosen
>>>>>>> Cc: SIMPLE mailing list
>>>>>>> Subject: Re: [Simple] MSRP
chat: SIP-based nickname negotiation
>>>>>>>
>>>>>>> Brian,
>>>>>>>
>>>>>>> What we are doing in SIMPLE is
specific to IM chat service (hence
>> the
>>>>>>> name of the draft). My opinion
is that whatever is in the draft is
>>>>>>> sufficient.
>>>>>>>
>>>>>>> Hisham
>>>>>>>
>>>>>>> On 17/05/07, Brian Rosen
<brbrianrosen.net> wrote:
>>>>>>>> I can see the registration
of a persistent nick as outside the
>>>> scope
>>>>>>> here.
>>>>>>>> We could do some
standardization, but we don't have to.
>>>>>>>>
>>>>>>>> However, we do need to
standardize how a nick user "validates" the
>>>>>> nick
>>>>>>>> against the AoR, if that is
what the domain wants to do.
>>>>>>>>
>>>>>>>> Nicks are not tied to
conferences. They can be used in other
>>>>>>> circumstances.
>>>>>>>> The validation operation
can't be tied to a conference server. I
>>>>>> don't
>>>>>>>> really care which IETF work
group does the work.
>>>>>>>>
>>>>>>>> In my experience,
conferences are the least common use of nicks.
>>>>>>> Persistent
>>>>>>>> nicks are much more common
than temporary nicks. If we're going
>>>>>> to bias
>>>>>>>> solutions, we ought to bias
them towards persistent, non conference
>>>>>>> nicks.
>>>>>>>> It's not clear to me that
we need such a bias.
>>>>>>>>
>>>>>>>> Brian
>>>>>>>>
>>>>>>>>> -----Original
Message-----
>>>>>>>>> From: Hisham Khartabil
[mailto:hisham.khartabilgmail.com]
>>>>>>>>> Sent: Wednesday, May
16, 2007 9:04 PM
>>>>>>>>> To: SIMPLE mailing
list
>>>>>>>>> Subject: Re: [Simple]
MSRP chat: SIP-based nickname negotiation
>>>>>>>>>
>>>>>>>>> This discussion is
great and helpful to the XCON folks. What we
>>>> are
>>>>>>>>> doing in SIMPLE is a
nickname service for an adhoc conference.
>>>>>> In my
>>>>>>>>> opinion, the solution
that Miguel and Aki are proposing in their
>>>>>> draft
>>>>>>>>> is sufficient enough to
satisfy the requirements of enabling a
>>>>>>>>> chatroom participant to
suggest a nickname for himself/herself
>>>>>> and get
>>>>>>>>> accepted into the
chatroom or get rejected with a reason of
>>>>>> conflict
>>>>>>>>> in nicknames. This is
on a first come first server basis.
>>>>>>>>>
>>>>>>>>> If a domain wants to
have the service where a user can have a
>>>>>> unique
>>>>>>>>> nickname across
chatrooms, then it is an implementation issue
>>>>>> behind
>>>>>>>>> the scenes and does not
require standardisation.
>>>>>>>>>
>>>>>>>>> If there are any other
requirements, including nickname
>>>> uniqueness
>>>>>>>>> across domains or the
reservation of a nickname forever, I think
>>>>>> they
>>>>>>>>> should go to XCON.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Hisham
>>>>>>>>>
>>>>>>>>>
_______________________________________________
>>>>>>>>> Simple mailing list
>>>>>>>>> Simpleietf.org
>>>>>>>>> https:/
/www1.ietf.org/mailman/listinfo/simple
>>>>>
_______________________________________________
>>>>> Simple mailing list
>>>>> Simpleietf.org
>>>>> https:/
/www1.ietf.org/mailman/listinfo/simple
>>>>>
>>>
>>>
_______________________________________________
>>> Simple mailing list
>>> Simpleietf.org
>>> https:/
/www1.ietf.org/mailman/listinfo/simple
>>>
>
_______________________________________________
Simple mailing list
Simpleietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple
|
