Subject: Re: [BLISS] Expert Review requests on Shared Line Appearance

From: Shida Schubert <[email-masked]>
Date: Mon, 6 Jul 2009 13:24:07 +0900

Alan;

  We are going to be talking to ADs this coming Tuesday,
I will inquire about the question on the appearance number
and extension of alert-info during the call.

  As for Appendix B, if people are happy with removing the text
and example call-flows that's fine. Appendix B is needed during
the process to ensure we evaluate pre-existing implementations
and options before coming up with best current practice. If we
are to remove the entire Appendix B, I would recommend we make
a note that pre-existing implementations were indeed evaluated
during the process.

  Regards
   Shida

On Jul 1, 2009, at 6:27 AM, Alan Johnston wrote:

> Andy,
>
> Thanks for this detailed review.  See my comments below.
>
> I also have a few questions for the chairs, which are summarized here:
>
> 1. How to proceed with Appendix A which defines a new Alert-Info  
> header field parameter?
> 2. Should we remove Appendix B on alternative approaches?
>
> Thanks,
> Alan
>
>
> Hutton, Andrew wrote:
>> Hi All,
>>
>> These are my review comments on draft-ietf-bliss-shared- 
>> appearances-02.
>>
>> Overall I think the draft covers most of the requirements but needs  
>> some
>> editorial work to remove some of the unnecessary sections and text. I
>> also think that it is necessary to explore some scenarios in more  
>> detail
>> especially the glare conditions. For example in 10.7 (appearance  
>> pickup)
>> what happens if the pickup fails and the already published state  
>> needs
>> to be cancelled.
>
> If the INVITE with Replaces fails (presumably because the dialog has  
> gone away or been marked exclusive), then the UQ will need to  
> PUBLISH again this failure.  I agree a call flow showing this would  
> be useful.  This would apply equally well to the INVITE Join case as  
> well.
>
>> It is the glare and recover scenarios that make this
>> feature so hard to implement and the draft says very little about
>> failure scenarios.
>>
>
> Yes, we need to include more failure and race conditions in the call  
> flows.  Your INVITE Replaces suggestion will be included - other  
> suggestions?
>
>> The inclusion of the appearance number in the incoming INVITE  
>> (appendix
>> A) is I believe a must have to make this work and should be a  
>> mandatory
>> part of the main specification.
>>
>
> I agree it is also very important.  I'd like to hear from the chairs  
> how we should proceed on this - I doubt that BLISS is chartered to  
> do a SIP extension such as a header field parameter.  Will we need  
> to discuss this in DISPATCH?  If so, it would be good to get started  
> on this now.
>
>> My detailed comments are as follows.
>>
>>
>> Section 1
>>
>> 3rd Para.
>> "Different approaches will be discussed including the use of URI
>> parameters....". Can we now remove the discussion on different
>> approaches.
>>
>
> This text is currently in Appendix B of the document.  I agree it is  
> not critical to an implementor, however, it is the kind of thing  
> that BLISS is chartered to do.  I'd like to hear the opinions of the  
> chairs and others on this.  I'm fine with either including or  
> removing Appendix B.
>
>> 4th Para.
>> "...gives this feature its" - Should this be "..its name" ?
>>
>>
>
> Yes.
>
>> Section 3.1
>> "An assistant can make outgoing calls using the identity of either  
>> the
>> executive or their own".  This should be removed as making calls with
>> the different identities is not part of this feature.
>>
>
> Agreed.
>
>
>> Section 3.2.
>>
>> Replace "SIP Telephony devices" with "SIP UA's" for consistency with
>> other sections.
>>
>
> Agreed.
>
>> Possibly replace "Another phone can request to be added to an  
>> appearance
>> resulting in a conference call" with "Another phone can request to be
>> added joined or bridged in with the existing appearance". Again  
>> this is
>> for consistency with section 3.3.
>>
>
> Yes.
>
>> Section 4.1.
>>
>> REQ-4 contains the statement "UAs registering against the group AOR
>> should be able to learn about each other and join the appearance  
>> group".
>> I don't think it is a requirement that the UA's "learn about each
>> other".
>>
>
> We were trying to say that UAs should not have to be configured with  
> information about other UAs in the group - I'll restate this  
> requirement.
>
>> Section 4.2.
>>
>> 4th Para. Contains the statement "The next section discusses normal  
>> SIP
>> operations used to implement parts of the shared appearance feature".
>> This refers to the bulleted list below which appears to contain many
>> statements that I would not include in "normal SIP operations" and
>> should be part of the normative section.
>>
>
> You are correct that this should not be described as "normal SIP  
> operations", so I'll get rid of that.  The steps in this list are  
> already repeated in normative language starting in Section 5.3.
>
>> Bullet 4 contains the statement "UAs receive a notification from the
>> Appearance Agent indicating the appearance number to use in rendering
>> the incoming call". I think it is a must that the incoming INVITE
>> contains the appearance number otherwise the UA cannot render the
>> incoming call until it receives this leading to all kind of race and
>> glare conditions.
>>
>
> This bullet should also mention the Alert-Info parameter as well.   
> If we make it mandatory, we will need to address which one has  
> precedence over the other, i.e. if Alert-Info says appearance 1  
> while the NOTIFY for the same early dialog says appearance 2.  I'd  
> vote for the NOTIFY having precedence.
>
>
>> Bullet 7. What does the UA publish in this scenario?
>>
>
> It is described in Section 5.3:
>
>  A UA wanting to place a call but not have an appearance number
>  assigned publishes before sending the INVITE without an 'appearance'
>  element but with the 'shared' event package parameter present.
> Perhaps a forward reference to this section would make this clearer.
>
>> Section 5.2.1.
>> The statement "When sent in a notification in state Trying to the
>> Appearance Agent" is incorrect because it is actually a publish  
>> which is
>> used.
>>
>
> You are correct.
>
>> Section 5.2.4
>>
>> Replace "convey" with "to convey".
>>
>
> Right.
>
>> Section 5.3.
>>
>> 1st Para. "defined in this draft". Please add a reference to the  
>> section
>> that defines this.
>>
>
> I will reference Section 11.1.
>
>> 3rd Para. "Upon initialization and at regular intervals, the UA  
>> SHOULD
>> subscribe" should replace the statement about regular intervals  
>> with a
>> reference to RFC 3265.
>>
>
> How about:
>
> Upon initialization, the UA SHOULD subscribe to the dialog event  
> package of the AOR and refresh the subscription per RFC 3265.
>
>
>> 3rd Para. "or returns a 482 Loop Detected" why is this singled out  
>> is it
>> just one of many possible failure cases.
>>
>
> I thought it was a likely error case.  We don't want an  
> implementation that gets an error at this stage to give up on the  
> entire shared appearances feature.
>
>
>> 4th Para. "User Agents MUST support sending an INVITE with a Join
>> [RFC3911] header field to initiate bridging". Why is this a MUST
>> strength requirement it should be optional for the UA to support
>> bridging so a MAY would seem to be appropriate.
>>
>
> I'm worried that if we made it less than a MUST, implementors will  
> just skip it and the resulting feature will be very weak.    I think  
> that only UAs that do line appearance monitoring don't need to  
> support Join.
>
>
>> 4th Para Note. "Note that the Join operation can be implemented  
>> outside
>> the UA, for example, in a B2BUA.  This is why UAs must support  
>> sending
>> Join header fields even if they do not necessarily support receiving
>> them". I think this can be removed and as previous comment I don't  
>> think
>> this is a reason for mandating that a UA can initiate bridging.
>>
>
> This is badly worded.  What is meant is that a UA can request to be  
> joined to another call even though it is not necessarily capable of  
> doing the mixing if another UA requests it.  Handling this kind of  
> asymmetric feature is something we've done very very badly in SIP,  
> I'm afraid.  I'll try to reword this text.
>
>
>> Section 7 (User Interface Considerations). I don't think we need this
>> section the purpose of the draft is to promote interoperability  
>> between
>> SA implementations. Those implementing this will be well aware of  
>> the UI
>> considerations that may be different depending on their particular  
>> type
>> of UA.
>>
>
> I think this section is useful.  Perhaps it would tie in better if  
> we had introduced these phones in Section 3.1.  What do others think  
> about this section?
>
>> Section 8.3.
>>
>> 1st Para. "This type of UA will be detected by the Appearance Agent  
>> by
>> the absence of the ma event parameter in SUBSCRIBE or PUBLISH  
>> messages"
>> I think the event type is "shared" not "ma" also if the UA does not
>> support SA then I assume it will not PUBLISH to the appearance agent.
>>
>>
>
> Yes, ma is from an older draft.  A non SA UA would not likely  
> PUBLISH but it may still SUBSCRIBE.
>
>
>> Section 10.1.
>> I think the REGISTER from bob needs to be shown.
>>
>
> OK.
>> Section 10.2
>>
>> 2nd Para. "then the Appearance Agent will need to resolve the  
>> situation
>> by moving either Alice or Bob's dialog to a different appearance".  
>> This
>> is one glare condition that I worry about what would happen if all  
>> other
>> appearances are busy ?.
>>
>
> Hmm.  This would imply an upper limit to the number of appearances  
> in the group.  We once had a requirement and scenarios for this but  
> they were removed as people thought they didn't fit the feature.  Of  
> course, a hard phone with lamps and buttons might run out of button  
> and lamp positions, but this should be addressed in Section 7.
>
>
>> The diagram seems to imply that the INVITE (F7/F8) is not sent to Bob
>> until after the NOTIFY's have been sent but I don't think this is the
>> case and it would therefore seem better to move the sending of the
>> INVITE to before the NOTIFY (F2/F4).
>
> Why?  The INVITE can not be forwarded with the appearance number  
> until the appearance agent knows about it and processes it.  In  
> processing the appearance number allocation, I would expect it to  
> immediately send NOTIFYs - for it to delay would not give a good  
> user experience for this feature.  As such, I prefer showing the  
> NOTIFYs arrriving first.  They are effectively happening in  
> parallel, although we have no way of showing that on the figure.   
> Some text perhaps could explain this.
>
>>
>> Section 10.7.
>> The PUBLISH (F32) indicating the dialog to be replaced is sent before
>> the INVITE/replaces (F38) is this the correct order and if so it
>> introduces some glare conditions that we need to explain how to get  
>> out
>> of.
>>
>
> Yes, this order is critical, otherwise the Appearance Agent will  
> probably reject the INVITE.  I agree we should show the case where  
> the PUBLISH succeeds but the INVITE Replace or Join fails.
>
>> Section 10.9.
>> It is not explained how Bob indicates in the PUBLISH that he does not
>> want an appearance number assigned.
>>
>
> How about adding this:
>
> He indicates this in his PUBLISH F32 by the inclusion of the  
> 'shared' event parameter with no <appearance> element.  This PUBLISH  
> is sent before the INVITE to Alice to ensure no appearance number is  
> assigned by the Appearance Agent.
>
>> The NOTIFY (F32) contains the dialog identifiers for the dialog with
>> alice but since the INVITE (F34) has not yet been generated it is  
>> likely
>> that Bob's UA will not know this information so it cannot be  
>> included in
>> the NOTIFY with state "trying".
>>
>
> This is the same thing we are doing in 10.4 and other places in this  
> specification.  If any dialog information is available, it should be  
> included in the publish.    This is described in Section 5.3:
>
>  Note that when a UA selects an appearance prior to establishment of a
>  dialog (#1 and #2 in above list), not all dialog information will be
>  available.  In particular, when a UA publishes an attempt to select
>  an appearance prior to knowing the destination URI, minimal or no
>  dialog information may be available.  For example, in some cases,
>  only the local target URI for the call will be known and no dialog
>  information.  If no dialog identification information is present in
>  the initial PUBLISH, the UA MUST PUBLISH again after receiving the
>  100 Trying response.
>
>> Section 12 Appendix A.
>> I think this should become part of the main specification and  
>> included
>> in the normative section.
>>
>
> Unless I am mistaken, I don't think that the BLISS WG can do this  
> work, so we will likely have to spin this off into a separate  
> document and reference it normatively in this document.
>
>> Section 13 Appendix B.
>>
>> I think this should be removed to reduce the size of the document.
>>
>>
>
> I am sympathetic to reducing the size.
>
>> Regards
>> Andy
>>
>>
>>
>>
>>
>
> _______________________________________________
> BLISS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bliss

---

From: Alan Johnston <[email-masked]>
Date: Tue, 14 Jul 2009 10:04:14 -0500

Francois,

Thanks for the review - I somehow lost track of it.  I think I have 
addressed nearly all of your comments in the latest revision.  See my 
comments below.

Thanks,
Alan

Francois Audet wrote:
> This is my expert review on draft-ietf-bliss-shared-appearances-02.
>
> Overall, document is in good shape and has no major issue. It would benefit
> from removing a lot of the "historical" or "discussion" material that is
> not relevant anymore.
>
> Also, I make some recommendation on how to make the Call flow examples clearer.
>
> This review also highlights the need for up-issuing draft-alexeitsev-bliss-alert-infor-urns
> (which is also needed by external standards bodies).
>
> ---------------------
>
>
> Section 1:
>
> 4th paragraph.
> NIT: incomplete sentence "...what gives this feature its.".
> NIT: s/lamp that can change color or blink/e.g.. a lamp that can change color or blink, or
> an screen icon
>   

Done.

>
> Section 4.2:
>
> p. 9, 2nd full paragraph: s/not discussed in this draft but instead is left as a 
> research project for future standardization/outside the scope of this draft
>   

Done.
> p. 10, bullet 5: Reword as follows:
>    5.  For outgoing calls, the operation depends on the implementation.
>        If line seizing is supported, the UA publishes this information and
>        waits for a 200 OK before sending the INVITE.
> (In other words, some implentations may allow for the user to "select" the appearance
> by pressing the button, but not seize the line. For that same reason, I'm changing "select"
> to "seize" in a few places in the document).
>   

I changed "select" to "select/seize" globally in the document.  I'm not 
sure it helps readability, but I think we need both terms.

>
> Section 5.3:
>
> p. 13, bullet 1: Reword as follows (this is same as previous point):
>
>    1.  When the user selects a particular appearance number for an outgoing 
>        and wishes to seize the apperance and appearing "off-hook" (if the UA's
>        user interface uses this methaphor).
>   

Done.

> 2nd paragraph after numbered items:  s/UA selects/UA seizes
>
> This section needs to describe that either a PUBLISH model or a SUBSCRIBE model can 
> be used for the state/appearance information to be sent to the Appearance Agent.
> Currently, it appears written for the PUBLISH model only. The SUBSCRIBE model, as 
> illustrated in section 10.13, is very useful for cases where the Appearance Agent
> is a stand-alone UA that does not share state/appearance information with the
> Proxy/B2BUA. This section also needs to describe that when the SUBSCRIBE model is used,
> the NOTIFY message is sent to "seize" a line (there is no need for a PUBLISH in this case).
> (I'm assuming I'm right: let's discuss if not).
>   

Good catch.  The draft is silent on this right now, so I've marked it as 
an open issue.  One one hand, I'd prefer to have only one mechanism 
(PUBLISH) for selection/seizure.  On the other hand, if the Appearance 
Agent has subscribed, and the UA is sending NOTIFYs, it hardly makes 
sense to mix PUBLISH into it.

> Section 8:
> Remove Editor's note.

Done.
>
> Section 9:
>
> Delete first paragraph.
>
> Clarify the UA also REGISTERs to the AOR. Discuss the security implications, i.e.,
> you either use the same shared username/password, or you use a different username/password
> for HTTP digest, per user. Perhaps the security considerations can be described in section 15.
>
>   

I added text about authorization for third party registrations and 
publication.  A little more text on this would be helpful.

> Section 10:
>
> General:
>
> The call flows are confusing because Alice is both the end user AOR, as well as the
> shared apperance AOR. This makes it very difficult to follow the call flows.
>
> I would like all the call flows to use Alice and Bob as the Endpoint, and the shared
> AOR to be, say, [email-masked] (or something similar). See below for details.
>   

I agree 100%.  I have changed the shared AOR to be 
sip:[email-masked] and I think this makes things clearer.  We need 
to make sure I've made all the correct substitutions in the call flows.

>
> Section 10.1:
>
> p. 22, 2nd paragraph: delete "or Appearance Agent" at end of paragraph.
>   

Actually, this is correct, as I am talking about registrations refresh 
with the Registrar and subscription refresh with the Appearance Agent.  
Here's the sentence:

 "Also note that registrations and subscriptions must all be refreshed
   by Alice at intervals determined by the expiration intervals returned
   by the Registrar or Appearance Agent."

Maybe it should say  Registrar and Appearance Agent?

> Figure 1 and Call Flow: I would like to also see Bob's registration, to
> illustrate the idea that Alice and Bob share the same AOR for both 
> registration and subscription.
>   

Done.

> Something like this:
>
>    Registrar     Appearance Agent          Alice           Bob
>    |                    |                    |              |
>    |                    |                    |              |
>    |<--------------------------- REGISTER F1<|              |
>    |                    |                    |              |
>    |>F2 200 OK ----------------------------->|              |
>    |                    |                    |              |
>    |                    |<----- SUBSCRIBE F3<|              |
>    |                    |                    |              |
>    |                    |>F4 202 Accepted -->|              |
>    |                    |                    |              |
>    |                    |>F5 NOTIFY -------->|              |
>    |                    |                    |              |
>    |                    |<-------- 200 OK F6<|              |
>    |                    |                    |              |
>    |<--------------------------- REGISTER F7---------------<|
>    |                    |                    |              |
>    |>F8 200 OK -------------------------------------------->|
>    |                    |                    |              |
>    |                    |<----- SUBSCRIBE F9---------------<|
>    |                    |                    |              |
>    |                    |>---------F10 202 Accepted ------->|
>    |                    |                    |              |
>    |                    |>--------F11 NOTIFY -------------->|
>    |                    |                    |              |
>    |                    |<-------- 200 OK F12--------------<|
>
> The, in the call flows, all the To headers for REGISTER 
> and SUBSCRIBE are <sip:[email-masked]> instead of 
> <sip:[email-masked]>.
>
> I REALLY think this will make the spec much more readable.
>
> Question: Why is "202" used for responding to SUBSCRIBE instead of "200"? If
> 202 is used, I think it deserves an explanation in the document.
>   

Isn't 202 commonly immediately returned, and then the NOTIFY confirms 
the subscription state (i.e. active instead of pending)?  I can change 
it to 200 if this is more common behavior.

>
> Section 10.2
>
> Again, all the AOR in "To" headers should be <sip:[email-masked]>
> (e.g., F7 & F8). This will help reader's understanding.
>
> Alert-Info in F7 should not use a <file://ring.pcm> example. 
> Preferably, we need to use a urn, like in draft-alexeitsev-bliss-alert-infor-urns.
> For example:
> 	Alert-Info: <urn:alert:tone>;alert=normal;appearances=1
>   

This is done as well, thanks to Laura for being the editor of this draft!

>
> Section 10.3
>
> In first paragraph, s/selecting/seizing.
>
> It would be useful to show the content of the NOTIFY messages going to Alice
> (e.g., F4).
>   

Done.
> I'm a bit confused by this example. It shows Bob making a call NOT using an 
> appearance (i.e., From: Bob instead of From: sharedline). And then both Alice
> and Bob are notified of Bob's state instead of the sharedline? Why is that
> a shared appearance scenario???
>   

Good catch!  This was a mistake - it now uses the shared AOR.

>
> Section 10.4
>
> Title: s/Pre-Selection/Seizing
>
> Again, use sip:[email-masked] when appropriate. 
> It would be nice to see the content of message 7.
>   

Done.

>
> Section 10.5
>
> Again, use sip:[email-masked] when appropriate. 
> It would be nice to see the content of message 7.
>
>   

It is the same as the previous message F7 - I put in a note saying that.

> Section 10.7
>
> Are messages F32-F35 necessary when line seizing is NOT used?
> I think the answer is "no, they would not be used if there is no
> line seizing". If so, I'd like to see a note explaining it.
>   

They are necessary for the Replaces and Join cases.  I added this text:

 "Alice must
   PUBLISH F32 to indicate that the INVITE F38 will be an attempt to
   pickup the dialog between Carol and Bob, and hence may use the same
   appearance number."

>
> Section 10.9
>
> Are messages F32-F33 necessary when line seizing is NOT used?
> I think the answer is "no, they would not be used if there is no
> line seizing". If so, I'd like to see a note explaining it.
>   

Again, they are necessary (this flow is now 10.10).

>
> Section 10.10
>
> Are messages F22-F23 necessary when line seizing is NOT used?
> I think the answer is "no, they would not be used if there is no
> line seizing". If so, I'd like to see a note explaining it.
>
>
> Section 10.13
>
> If the Appearance Agent subscribes to Bob's dialog-event package (as
> in this example), is the expectation that Bob would never really use 
> PUBLISH, and rather, would always use NOTIFY? I am assuming that the
> answer is yes.
>   

We do need to resolve this and document the right answer.

> I am also assuming that it would even be the case for the line
> seizing mechanism. Is this correct?
>
> If this is the case, it would be useful to section 10 (before the 
> individual call flows) that all the sections expect 1.13 use a model
> where the Appearance agent does NOT use a subscription model, but a 
> publish model instead. And then add a note that if a subscription model
> was used instead, there would be NOTIFYs instead of PUBLISHes, as per 
> section 10.13.
>   

OK, I meant to include this text but left it out.  I think it is a good 
idea.

>
> Section 11.1
>
> First line: delete "also".
>   

Done.

>
> Section 12 Appendix A
>
> This whole section should not be an Appendix and should be moved to the core 
> document; it seems this section is necessary for REQ-9.
>
> Alert-Info should not use a <file://ring.pcm> example. 
> Preferably, we need to use a urn, like in draft-alexeitsev-bliss-alert-infor-urns.
> For example:
> 	Alert-Info: <urn:alert:tone>;alert=normal;appearances=1
>
> (I think that "tone" one is the default, so we can get rid of the OPEN issue.
> Need to add draft-alexeitsev-bliss-alert-infor-urns to References. Also need
> to up-issue that draft and move it forward).
>   

Right, done.

>
> Section 13: Appendix B
>
> I think it is time to remove this whole Appendix B. This whole section was useful
> reference when we were discussing various options, but now, it is totally out of
> place since the choices have been made.
>
>   

Done.

> Section 15: Security Considerations
>
> See comment on section 9.
>
>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jul 2009 15:45:50 -0500

Thanks Alan. Looks good.

Since the vast majority of my comments are addressed by this new draft,
I'll do individual replies for the ones requiring more discussion/
clarification.

Cheers.

> -----Original Message-----
> From: Alan Johnston [mailto:[email-masked]] 
> Sent: Tuesday, July 14, 2009 08:04
> To: Audet, Francois (SC100:3055)
> Cc: [email-masked]
> Subject: Re: Expert Review requests on Shared Line Appearance
> 
> Francois,
> 
> Thanks for the review - I somehow lost track of it.  I think 
> I have addressed nearly all of your comments in the latest 
> revision.  See my comments below.
> 
> Thanks,
> Alan

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jul 2009 16:27:46 -0500

> I changed "select" to "select/seize" globally in the 
> document.  I'm not sure it helps readability, but I think we 
> need both terms.

Here is an explanation what I meant with "seize" versus "select".
I might have been using a definition of "selection" that is different
from what you had in mind.

In my mind, I was equating "seizing" with the concept of actually
reserving the AOR for ones self by PUBLISHing (or NOTIFYing) the
Appearance agent of the call state "premptively".

In contrast, I was using the term "selection" to mean the local
action (on the phone) of choosing which "line" to use (i.e., the
"From" header). This is local because it does not require any
publication of state to the appearance agent. The user presses
a line key, no signalling comes out immediately (and user probably
hears dial tone). When the call is eventually made, it uses that 
line that was "selected" as the originator (i.e., the From header).

I am proposing that if we use these definitions, then it makes it much
clearer throughout the document what we are talking about. There are
lots of cases where we mean "selection or seizing" (because the PUBLISH/
SUBSCRIBE is optional), and in other cases, we really mean the
"seizing".

So, for example, in 10.4, messages F1-F2 are actually a "seizing", not 
merely a "selection".

Anyways, just think about it. 

I think there are people who would want to implement the "line seizure" 
concept, and people who would NOT want to implement it. If it's clear
what "seizure" means, then it makes it obvious in the text what is the
optional part.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jul 2009 16:32:21 -0500

> sense to mix PUBLISH into it.

I believe the approach of using SUBSCRIBE instead of PUBLISH in this case
makes much more sense.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jul 2009 17:29:30 -0500

> > for HTTP digest, per user. Perhaps the security 
> considerations can be described in section 15.
> >
> >   
> 

Ah-ah... Now we are getting down to business.

I am now looking at new section 10.1 on registration, and I see that
you are using indeed third-party registration (with To=HelpDesk, 
From=Alice).

So, this would be one way to to it.

Another way would be to NOT use third-party registration at all. In 
other words, Alice would send a first party registration on behalf
of HelpDesk (ie.., To=HelpDesk, From=Alice).

Wouldn't that work?

Then there is the whole issue of authentication with HTTP-Digest.
I guess one could use username="HelpDesk". In this case, the idea is that
Alice would need to know the credentials for HelpDesk. 
Another way would be to use username="alice" instead (i.e., her own credentials).
The decisions on which authentication you use would depend on need of the 
administrator.

Have you tought about this? Am I off based?

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jul 2009 18:16:17 -0500

Ok, these are the final nits. 

---------------------

> Maybe it should say  Registrar and Appearance Agent?

Ah, I get it now. What about this:

	Also note that both registrations and subscriptions must all be 
	refreshed by Alice at intervals determined by the expiration 
	intervals returned respectively by the Registrar and the 
	Appearance Agent.

---------------------

> the subscription state (i.e. active instead of pending)?  I 

Not exactly.

>From 3265:

	A 200 response indicates that the subscription has been accepted 
	and that the user is authorized to subscribe to the requested 
	resource.  A 202 response merely indicates that the subscription 
	has been understood, and that authorization may or may not have 
	been granted.

Now, in draft-roach-sipcore-rfc3265bis-00 Appendix B, I see this:

B.2.  Remove 202 Response Code?

   In practice, the 202 response code defined in RFC 3265 has proven to
   be nearly useless, due to its redundancy with the "pending" state,
   and its interaction with the HERFP problem.  Given that 202 must be
   treated as 200 if an implementation does not understand it: would
   removing the 202 response code cause any issues for current
   implementations?

I know it's not a done deal yet (this is not even a WG document), but
unless you see a really good reason why this spec would use 202 instead 
of 200 in the examples, I'd rather we play it safe and use 200...

-------------

Section 10

Add note after first paragraph:

	Note: All the examples in this section, except Section 10.13, show
	a model where the Appearance Agent has access to dialog state information
	and therefore does not explicitly subscribe to the dialog-event package.
	All these examples would be different if an explicit subscription was used
	instead. For simplicity, only one example of subscription is shown (see
	Section 13): but the same idea could be applied throughout all the examples.

Or something like that. You get the idea.

What I found is that if you are designing your implementation using the subscription
model, then it takes a while to figure out that the spec is still applicable to you.
And section 10.13 is burried quite deep at the end.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 15 Jul 2009 08:55:22 +0100

Hi,

If "select" is a local action in the UA to choose a "line" to use and
this determines the what is in the from header then this is I believe
out of scope for this draft which should not mention selecting lines or
AOR's as this is a different feature. The SA draft is limited to sharing
appearances of the same AOR.

Also if "select" is a local action at the UA that is just UI behaviour
then probably no need to mention it at all.

Regards
Andy

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Francois Audet
>Sent: 14 July 2009 22:28
>To: Alan Johnston
>Cc: [email-masked]
>Subject: [BLISS] draft-ietf-bliss-shared-appearances: Seize vs Select
>
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 15 Jul 2009 11:53:57 +0100

Indeed this getting interesting.

In version -02 the REGISTER in section 10.1 showed a normal 1st party
registration by alice but -03 shows a third party registration which is
a significant change.

I must admit I missed the text in -02 which stated "Bob and Alice are in
an appearance group identified by Alice's AOR. Bob REGISTERs using
contact sip:[email-masked]" and I should have commented on that
earlier.

As the draft is about sharing appearances of a single AOR then surely
third party registration is not necessary as it could be that there is
simply two helpdesk phones using a single AOR and there is no "alice" or
"bob" AOR's. So in the simplest case the REGISTER would be:

   REGISTER sip:registrar.example.com SIP/2.0
   Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09
   From: <sip:[email-masked]>;tag=CDF9A668-909E2BDD
   To: <sip:[email-masked]>
   CSeq: 2 REGISTER
   Call-ID: d3281184-518783de-cc23d6bb
   Contact: <sip:[email-masked]>

Regards
Andy

>Sent: 14 July 2009 23:30
>Subject: [BLISS] draft-ietf-bliss-shared-appearances: 
>Provisioningconsiderations
>
>
>> > Section 9:
>> >
>> > Delete first paragraph.
>> >

---

From: Venkatesh <[email-masked]>
Date: Wed, 15 Jul 2009 08:45:33 -0700

Andrew:
Thanks for pointing it out. I missed the change as well. Honestly, one of
the main use cases for BLA/SLA was to address a boss/secretary scenario. In
these cases, the secretary is really monitoring a "Boss" extension; so from
a "ownership" purpose, the AoR is really that of the boss and not a "common"
address.

Venkatesh

On Wed, Jul 15, 2009 at 3:53 AM, Hutton, Andrew <
[email-masked]> wrote:

> contact sip:[email-masked] <[email-masked]>" and I should
> have commented on that
> earlier.
>
>   From: <sip:[email-masked] <[email-masked]>
> >;tag=CDF9A668-909E2BDD
>   To: <sip:[email-masked] <[email-masked]>>
>   CSeq: 2 REGISTER
>   Contact: <sip:[email-masked] <[email-masked]>>
>
> Regards
> Andy
>
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Jul 2009 11:02:12 -0500

Hi Andrew,

That's what I was thinking too for the two fields of importance here,
i.e., the To and the From.

I will point out that the Contact is completely up to the UA to 
decide (as long as it routes).

Specifically, in this case, Bob could use:
Contact: <sip:[email-masked]>  

Or even:
Contact: <sip:[email-masked]>

Or
Contact: <sip:[email-masked];token=bob>

...you get the idea.

The reason why you may need to use something else than
HelpDesk as the contact is for cases where you need
to associate the signalling to a specific user.

For example, many phones allow for multiple 
users to be logged in simultaneaously (i.e., 
multiple accounts).

Think of a phone, for example, that happens to have
both Alice and Bob logged in on the same phone, and each
one having a shared appearance of HelpDesk./

> From: Hutton, Andrew [mailto:[email-masked]] 
> Sent: Wednesday, July 15, 2009 03:54
> To: Audet, Francois (SC100:3055); Alan Johnston
> Cc: [email-masked]
> Subject: RE: [BLISS] draft-ietf-bliss-shared-appearances: 
> In version -02 the REGISTER in section 10.1 showed a normal 
> 1st party registration by alice but -03 shows a third party 
> registration which is a significant change.
> 
> I must admit I missed the text in -02 which stated "Bob and 
> Alice are in an appearance group identified by Alice's AOR. 
> Bob REGISTERs using contact sip:[email-masked]" and I 
> should have commented on that earlier.
> 
> As the draft is about sharing appearances of a single AOR 
> then surely third party registration is not necessary as it 
> could be that there is simply two helpdesk phones using a 
> single AOR and there is no "alice" or "bob" AOR's. So in the 
> simplest case the REGISTER would be:
> 
> >other words, Alice would send a first party registration on 
> behalf of 
> >HelpDesk (ie.., To=HelpDesk, From=Alice).
> >
> >Wouldn't that work?
> >
> >I guess one could use username="HelpDesk". In this case, the idea is 
> >that Alice would need to know the credentials for HelpDesk.
> >The decisions on which authentication you use would depend 
> on need of 
> >the administrator.
> >

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Jul 2009 11:29:22 -0500

Yes, of course HelpDesk could be the Boss instead.

________________________________

	From: Venkatesh [mailto:[email-masked]] 
	Sent: Wednesday, July 15, 2009 08:46
	To: Hutton, Andrew
	Cc: Audet, Francois (SC100:3055); Alan Johnston; [email-masked]
	Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: Provisioningconsiderations

	Andrew: 

	Thanks for pointing it out. I missed the change as well. Honestly, one of the main use cases for BLA/SLA was to address a boss/secretary scenario. In these cases, the secretary is really monitoring a "Boss" extension; so from a "ownership" purpose, the AoR is really that of the boss and not a "common" address.

	Venkatesh

	On Wed, Jul 15, 2009 at 3:53 AM, Hutton, Andrew <[email-masked]> wrote:

		
		I must admit I missed the text in -02 which stated "Bob and Alice are in
		an appearance group identified by Alice's AOR. Bob REGISTERs using
		contact sip:[email-masked] <mailto:[email-masked]> " and I should have commented on that
		earlier.

		  REGISTER sip:registrar.example.com SIP/2.0
		  Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09
		  From: <sip:[email-masked] <mailto:[email-masked]> >;tag=CDF9A668-909E2BDD
		  To: <sip:[email-masked] <mailto:[email-masked]> >
		  CSeq: 2 REGISTER
		  Call-ID: d3281184-518783de-cc23d6bb
		  Contact: <sip:[email-masked] <mailto:[email-masked]> >
		
		Regards
		Andy

---

From: Venkatesh <[email-masked]>
Date: Wed, 15 Jul 2009 09:36:05 -0700

Sure, but it means the secretary is now using HelpDesk (or "boss" in the
example) credentials to register if you didn't have 3rd party registration
semantics?
Venkatesh

On Wed, Jul 15, 2009 at 9:29 AM, Francois Audet <[email-masked]> wrote:

>  ------------------------------
> *From:* Venkatesh [mailto:[email-masked]]
> *Sent:* Wednesday, July 15, 2009 08:46
> *To:* Hutton, Andrew
> *Cc:* Audet, Francois (SC100:3055); Alan Johnston; [email-masked]
> *Subject:* Re: [BLISS] draft-ietf-bliss-shared-appearances:
>>   Contact: <sip:[email-masked] <[email-masked]>
>> >
>>
>> Regards
>> Andy
>>
>>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Jul 2009 11:56:44 -0500

Well, yes.
 
However, as per my email, that's not the only alternative.
 
You could use "user=alice" for authentication in HTTP digest if, for whatever reason, you prefer to have users authenticating as themselves instead of using the shared appearance. That advantage is that users don't need to know 2 username/passwords. The disadvantage is that you need more infrastructure in the back-end to allow Alice to log in as Boss with her own credential. 
 
I was thinking that both model should be allowed. Like in most SIP client today, you can put a different HTTP credential (if required).
Otherwise, it would default to the one used for registering (i.e., the From).
 
So in both cases, there is no 3rd party registration per se (as per the definition in 3261).
 
That was my thought

	From: Venkatesh [mailto:[email-masked]] 
	Sent: Wednesday, July 15, 2009 09:36
	To: Audet, Francois (SC100:3055)
	Cc: Hutton, Andrew; Alan Johnston; [email-masked]
	Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: Provisioningconsiderations

	Sure, but it means the secretary is now using HelpDesk (or "boss" in the example) credentials to register if you didn't have 3rd party registration semantics? 

	Venkatesh

			Andrew: 

			Venkatesh

				

				
				
				Regards
				Andy

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Jul 2009 11:19:08 -0500

I disagree. I think we need some clarification.

We have decided already that the act of "fake publishing" a "trying" state
is OPTIONAL in this draft. This feature is really when a vendor 
wants to mimic traditional behavior of a key system.

Other people view this as an archaic limitation instead. Even in
"pre-sip" implementations, many TDM PBXs have given up already
on "seizing" lines when you press the button (the "seizing" only
occurs when the call is actually made).

So, we wisely opted to make this optional in the spec. The problem
is that we have a bit of lack of clarity in a few places about what
that means.

Getting to specifics, if you look at example 10.4 of the spec.
If you use a "selection model" instead of a "seizing" model,  then
messages F1-F6 do not occur. And neigther would messages F10-F11. 

(Note that if the Appearance agent had subscribed to HelpDeksk's
dialog state, then there would be NOTIFY instead of F10: that is
the subject of another discussion).

If we agree on this, I can volunteer to provide text if Alan wants
it. But I'm not sure if "selection" is the proper term. An alternative
would be to say the line is "Seized" or "Not Seized".

> Sent: Wednesday, July 15, 2009 00:55
> Seize vs Select
> If "select" is a local action in the UA to choose a "line" to 
> use and this determines the what is in the from header then 
> this is I believe out of scope for this draft which should 
> not mention selecting lines or AOR's as this is a different 
> feature. The SA draft is limited to sharing appearances of 
> the same AOR.
> 
> Also if "select" is a local action at the UA that is just UI 
> behaviour then probably no need to mention it at all.
> 
> Regards
> Andy
> 
>  
> 
> document.  I'm 
> >> not sure it helps readability, but I think we need both terms.
> >
> >In contrast, I was using the term "selection" to mean the 
> local action 
> >(on the phone) of choosing which "line" to use (i.e., the "From" 
> >header). This is local because it does not require any 
> publication of 
> >state to the appearance agent. The user presses a line key, no 
> >signalling comes out immediately (and user probably hears 
> dial tone). 
> >When the call is eventually made, it uses that line that was 
> "selected" 
> >as the originator (i.e., the From header).
> >
> >lots of cases where we mean "selection or seizing" (because the 
> >PUBLISH/ SUBSCRIBE is optional), and in other cases, we 
> really mean the 
> >"seizing".
> >

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 16 Jul 2009 11:29:54 -0500

Ok, I think we are on the same page then. 

I was thinking something along the lines of having a "terminology
section" (like most drafts) including something like:

Seizing: An appearance can be seized by communicating an
artificial state of "trying" prior to actually initiating a dialog,
in order to appear as it was already initiating a dialog. 

Selecting(or Not-Seizing): An appearance is merely selected
(i.e., not seized) if there is no such communication of 
artificial state of "trying" prior to initiating a dialog:
i.e., the state is communicted when the dialog is actually
initiated. 

I'm not attached to using the term "selected". I would just
like the distinction to be clear so when developpers read
the procedures (and more importantly the example), they
know which parts are optional.

It's perfectly fine with me if at the end of the day,
a phone can be described as "Support Appearance Seizure: yes or no"
instead of "Appearance: Seizure vs Selection".

> Sent: Thursday, July 16, 2009 09:18
> See below.
> >From: Francois Audet [mailto:[email-masked]]
> >Sent: 15 July 2009 17:19
> >To: Hutton, Andrew; Alan Johnston
> >Cc: [email-masked]
> [Andy H] OK Clarification is always a good thing.
> 
> 
> >We have decided already that the act of "fake publishing" a "trying" 
> >state is OPTIONAL in this draft. This feature is really when 
> a vendor 
> [Andy H] I Agree.
> [Andy H] I Agree.
> [Andy H] I Agree.
> [Andy H] I agree except that I object to is any discussion about line
> selection as we will not be able to agree on what is meant by a "line"
> we went over this many times already it is an an appearance 
> index which
> is "seized" or "not siezed" and not a line which many people relate to
> an AOR.
> 
> 
> 
> 
> >
> >

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 16 Jul 2009 17:17:58 +0100

Hi All,

See below.

Regards
Andy

[Andy H] I Agree.

[Andy H] I Agree.

[Andy H] I Agree.

[Andy H] I agree except that I object to is any discussion about line
selection as we will not be able to agree on what is meant by a "line"
we went over this many times already it is an an appearance index which
is "seized" or "not siezed" and not a line which many people relate to
an AOR.

---

From: Alan Johnston <[email-masked]>
Date: Thu, 16 Jul 2009 13:42:30 -0500

So it sounds like we are all on the same page, that we are talking about 
only one AOR, the shared appearances AOR.  So lines or alternative AORs 
are not mentioned in this document.

See my comments below.

Thanks,
Alan

> i.e., the state is communicted when the dialog is actually

So, using this terminology, selecting is a UI operation that has no 
protocol implications on the wire.  I think we already cover this in the 
draft, but don't talk about the UI.

 From the protocol perspective, there are four options when it comes to 
appearances:

1. The UA seizes the appearance prior to sending the INVITE - this is 
the old fashioned mechanism and requires the PUBLISH prior to the INVITE.
2. The UA just sends the INVITE and the Appearance Agent assigns the 
appearance number for it.  The UA will update its UI once it knows the 
appearance number.
3. The UA does not want to assign an appearance number for a call using 
the shared AOR. This is the consultation call case.  The PUBLISH must be 
sent before the INVITE so the Appearance Agent does not assign a new 
appearance number by mistake.
4. The UA is going to take or join another appearance, so it wants to 
reuse the existing appearance number.  Again, a PUBLISH must be sent 
before the INVITE so the Appearance Agent does not assign a new 
appearance number by mistake.  Also, the joined-dialog or 
replaced-dialog elements tell the Appearance Agent that a take or join 
is in progress, so it does not reject the PUBLISH with a 409 due to the 
appearance number already being in use.

> instead of "Appearance: Seizure vs Selection".

OK, but even UAs that do no seize appearances must be able to handle 
scenarios 2-4 above, some of which involve sending the PUBLISH prior to 
the INVITE.
>>> it. But I'm not sure if "selection" is the proper term. An 
>>>       
>> alternative
>>     
>>>> On Behalf 
>>>>> Of Francois Audet
>>>>> Subject: [BLISS] draft-ietf-bliss-shared-appearances: Seize 
>>>>>           
>>> vs Select
>>>       
>>>>>           
>>>>> I might have been using a definition of "selection" that is 
>>>>>           
>>>> different 
>>>>> I am proposing that if we use these definitions, then it 
>>>>>           
>>>> makes it much 
>>>>         
>>>>> clearer throughout the document what we are talking about. 
>>>>>           
>>> There are 
>>>       
>>>>> So, for example, in 10.4, messages F1-F2 are actually a 
>>>>>           
>>>> "seizing", not 
>>>>         
>>>>> merely a "selection".
>>>>>
>>>>> I think there are people who would want to implement the 
>>>>>           
>>>> "line seizure"
>>>>         
>>>>> concept, and people who would NOT want to implement it. If 
>>>>>           
>>>> it's clear 
>>>>         
>>>>> what "seizure" means, then it makes it obvious in the text 
>>>>>           
>>>> what is the 
>>>>         
>>>>> optional part.

---

From: Alan Johnston <[email-masked]>
Date: Thu, 16 Jul 2009 13:47:38 -0500

So you are proposing that Bob would register like this:

REGISTER
To: <sip:[email-masked]>
From: <sip:[email-masked]>

but when challenged, provide the credentials for user Bob instead of the 
HelpDesk?  This seems like a bad idea to me.  Why isn't this 3rd party 
registration:

REGISTER
To: <sip:[email-masked]>
From: <sip:[email-masked]>

And when challenged, Bob provides his credentials.  The Registrar is 
provisioned to allow Bob to register against HelpDesk and everything 
works.  Alternatively, you could have Bob register using:

REGISTER
To: <sip:[email-masked]>
From: <sip:[email-masked]>

But he will need to have the credentials for HelpDesk when challenged.

Anyway, we and other vendors already implement this feature this way, so 
the draft must support it.  A given system can choose not to use it.

Thanks,
Alan

Francois Audet wrote:
> You could use "user=alice" for authentication in HTTP digest if, for 
> whatever reason, you prefer to have users authenticating as themselves 
> instead of using the shared appearance. That advantage is that users 
> don't need to know 2 username/passwords. The disadvantage is that you 
> need more infrastructure in the back-end to allow Alice to log in as 
> Boss with her own credential.
>  
> I was thinking that both model should be allowed. Like in most SIP 
> client today, you can put a different HTTP credential (if required).
>     ------------------------------------------------------------------------
>     *Sent:* Wednesday, July 15, 2009 09:36
>     *To:* Audet, Francois (SC100:3055)
>     *Cc:* Hutton, Andrew; Alan Johnston; [email-masked]
>     Sure, but it means the secretary is now using HelpDesk (or "boss"
>     in the example) credentials to register if you didn't have 3rd
>     party registration semantics?
>
>     Venkatesh
>
>     On Wed, Jul 15, 2009 at 9:29 AM, Francois Audet <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>             ------------------------------------------------------------------------
>             *From:* Venkatesh [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             *Cc:* Audet, Francois (SC100:3055); Alan Johnston;
>             [email-masked] <mailto:[email-masked]>
>             *Subject:* Re: [BLISS]
>             Thanks for pointing it out. I missed the change as well.
>             Honestly, one of the main use cases for BLA/SLA was to
>             address a boss/secretary scenario. In these cases, the
>             secretary is really monitoring a "Boss" extension; so from
>             a "ownership" purpose, the AoR is really that of the boss
>             and not a "common" address.
>
>             Venkatesh
>
>             On Wed, Jul 15, 2009 at 3:53 AM, Hutton, Andrew
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>
>                 contact sip:[email-masked]
>                 <mailto:[email-masked]>" and I should have
>                 commented on that
>                 earlier.
>
>                   REGISTER sip:registrar.example.com
>                 <http://registrar.example.com> SIP/2.0
>                   Via: SIP/2.0/UDP ua1.example.com
>                 <http://ua1.example.com>;branch=z9hG4bK527b54da8ACC7B09
>                   From: <sip:[email-masked]
>                 <mailto:[email-masked]>>;tag=CDF9A668-909E2BDD
>                   To: <sip:[email-masked]
>                 <mailto:[email-masked]>>
>                   CSeq: 2 REGISTER
>                   Contact: <sip:[email-masked]
>                 <mailto:[email-masked]>>
>
>                 Regards
>                 Andy
>
>
>                 >From: [email-masked]
>                 <mailto:[email-masked]>
>                 [mailto:[email-masked]
>                 <mailto:[email-masked]>]
>                 >Cc: [email-masked] <mailto:[email-masked]>
>                 >> > you either use the same shared username/password,
>                 or you
>                 >> use a different username/password
>                 >I guess one could use username="HelpDesk". In this
>                 case, the
>                 >idea is that
>                 >Another way would be to use username="alice" instead
>                 (i.e.,
>                 >her own credentials).
>                 >The decisions on which authentication you use would
>                 depend on
>                 >need of the
>                 >administrator.
>                 >
>                 >[email-masked] <mailto:[email-masked]>
>                 [email-masked] <mailto:[email-masked]>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 16 Jul 2009 14:13:51 -0500

I don't have a strong opinion one way or another, but I think 
the point is that we decide, and document it.

It's not clear to me why the first method (3rd party authentication) is
"a bad idea" and the second one (3rd party registration) is a good one.
Can you clarify why it's bad?

I *think* (I could be wrong) the 3rd party authentication would be supported
by any UA today that supports a separate "Authorization name" (or "realm auth" or
whatever it is called). In contast, I haven't seen many UAs supporting 3rd 
party registration.

Furthermore, in 3261, your would assume that the username in the credentials
be the same as the userinfo part of the To header (3261/26.3.2.1). In what you are
describing here for 3rd party registration, in contast, you are using for the username, 
the userinfo of the From header. 

In other words, any way we choose to go, we are changing the way you'd normally expect 
authentication to work.

Anyways, to summarize: I don't have a strong opinion. Just pick one, and document
it in the draft. I think leaving it open to interpretation will cause interoperability
issues.

----

PS:

Finally, for the last case in your email, i.e., From/To/Http-digest-credentials = HelpDesk,
we are in 100% agreement. That's also what we have done. We should describe it in the text.

> Sent: Thursday, July 16, 2009 11:48
> Cc: Venkatesh; Hutton, Andrew; [email-masked]
> but when challenged, provide the credentials for user Bob 
> instead of the HelpDesk?  This seems like a bad idea to me.  
> Why isn't this 3rd party
> registration:
> 
> REGISTER
> And when challenged, Bob provides his credentials.  The 
> Registrar is provisioned to allow Bob to register against 
> HelpDesk and everything works.  Alternatively, you could have 
> Bob register using:
> 
> REGISTER
> Anyway, we and other vendors already implement this feature 
> this way, so the draft must support it.  A given system can 
> choose not to use it.
> 
> Thanks,
> Alan
> 
> Francois Audet wrote:
> > Well, yes.
> >  
> > Otherwise, it would default to the one used for registering 
> (i.e., the 
> > From).
> >  
> >                 As the draft is about sharing appearances 
> of a single
> >                 AOR then surely
> >                 third party registration is not necessary 
> as it could
> >                 be that there is
> >                 >> > Clarify the UA also REGISTERs to the 
> AOR. Discuss the
> >                 >> security implications, i.e.,
> >                 >I am now looking at new section 10.1 on 
> registration,
> >                 and I see that
> >                 >Then there is the whole issue of 
> authentication with
> >                 HTTP-Digest.